Human machine interface

ABSTRACT

An industrial control user interface provides a flexible, extensible architecture for the provision of real-time process data to a state-of-the-art user interface, using MSHTML as the underlying rendering engine. The architecture of the interface provides a user interface that is designed to harness key industry standard technologies in an open, adaptable, architecture that facilitates the technological convergence of disparate HMI products. The preferred embodiments offer open display page architecture via the separation of the provision of data and server specific user interactions from the implementation of individual page elements. The only real assumption made about a page element is that it is part of the HTML display page and accessible via the Document Object Model.

FIELD OF INVENTION

[0001] The present invention relates to a human machine interface (HMI).

[0002] The invention has been developed primarily for Industrial,Security, Life Safety, Access Control, Heating, Ventilation and AirConditioning applications such as the monitoring of data generated byindustrial processes and equipment, and will be described hereinafterwith reference to that application. However, it will be appreciated thatthe invention is not limited to use in that particular field.

BACKGROUND OF THE INVENTION

[0003] Remote monitoring of data is frequently used in industrialsettings. The desire for implementing such monitoring ranges from theneed for centralised monitoring of relatively complex industrial systemsto the convenience of allowing a small number of operators to monitormultiple data streams via a single workstation. In many cases, it isalso desirable that the HMI allow operators to control at least some ofthe industrial processes and machines in relation to which the data isbeing collected.

[0004] Historically, collection and display of industrial data onoperator workstations has been dealt with on a proprietary basis, withapplication-specific software linking remote data sources with dedicatedterminals. Whilst such systems have provided satisfactory performance,they are relatively time consuming to design, and relatively inflexibleonce implemented.

[0005] Another problem is that individually implemented softwaresolutions are often limited in the types of data sources with which theycan interface.

[0006] One of the most profound developments of the last five years hasbeen the staggering growth of the internet. This growth has changedpublic perceptions about the availability of data, about what to expectin a user interface, and how open and interoperable computer systemsshould be. Standalone computer systems are no longer acceptable to themarket—the increasingly networked world is setting the pace and scope ofchange.

[0007] In addition, this growth has led to a huge shift in developmentfocus for practically every software organisation. The web has becomethe ubiquitous data delivery mechanism, and as software organisationsfocus their energies on harnessing its potential, the technologies whichunderpin its success are being pushed forward at ever-increasing rates.Where once the web was not mature enough to support mission-criticalfunctions, such as major financial transactions or process control, itis clear that this is no longer the case.

[0008] It is this growth which is driving investment into user interfacetechnology, as the major stakeholders seek to establish the internet asa viable business platform. As a result, current technological trendshave meant the underlying technologies are becoming increasingly moreappropriate to the field of industrial process control.

[0009] The development of what may be loosely termed “internettechnologies” has been extremely rapid, and has a very short history:

[0010] December 1993: Only 200 known http servers existed.

[0011] December 1994: First W3C meeting. Over 200 members, charter topromote interoperability.

[0012] October 1996: OLE Controls 96 Specification published. Promoteslightweight, windowless controls suitable for the web environment, andintended to add increasing sophistication to browser capabilities.

[0013] December 1996: Cascading Style Sheet specification. Introduced 2Dpositioning, size, colour, font attributes.

[0014] July 1997: HTML 4.0 specification. Included scripts, objects,framesets, internationalisation. Browser technology advancedappropriately.

[0015] September 1997: Dynamic HTML, Document Object Model. Full accessto the HTML object model, providing web pages with unprecedented powerand flexibility.

[0016] September 1998: Internet Explorer 5.0 Beta 2. Includes VectorMarkup Language for vector graphics capabilities.

[0017] late 1999: Office 2000 to use HTML/XML as document format for allsuite products. Microsoft look to include sufficient functionality inHTML for it to be suitable for use by Visual Basic forms engine.

[0018] In parallel with these developments has been an increasingawareness that HTML's origins as a language intended to storepresentation information means its ability to store and represent datais severely limited. This limitation has led to the rise of XML, orextensible Markup Language, intended to work in concert with HTML toprovide a means of storing both data and presentation information.

[0019] It was these trends that led the applicant to consider thesuitability of such technologies for industrial control systems.

[0020] The development requirements of an industrial control systemindicate clearly that known web browsers are not suitable for theoperator environment of an industrial control system. They may beacceptable for casual use, but the operator environment has specificrequirements, such as restricted navigation, support for industrialkeyboards, alarm and status indication, and security.

[0021] The partial solution to a number of these issues may be providedusing a software package sold and marketed by Microsoft®. In particular,Microsoft® supply a rendering engine used in Internet Explorer (known asMSHTML), for use by third-party developers wishing to integrate HTMLrendering capabilities into their applications. While this softwarepackage can represent a useful tool for system designers, its genericnature ensures that it will not automatically integrate or interact withother applications. Further although the invention in some aspects willbe described in relation to this software package, it will beappreciated that other browser techniques may be used.

[0022] Any discussion of the prior art throughout the specificationshould in no way be considered as an admission that such prior art iswidely known or forms part of common general knowledge in the field.

DISCLOSURE OF THE INVENTION

[0023] It is an object of the present invention to overcome orameliorate at least one of the disadvantages of the prior art, or toprovide a useful alternative.

[0024] According to a first aspect of the invention there is provided aHuman Machine Interface (HMI) including:

[0025] a display page including a plurality of display page elements;

[0026] a data source manager including a plurality of data sourcecomponents; and

[0027] a binding engine which transfers data and commands between thedata source components and the display page elements.

[0028] Preferably, the display page further includes a plurality ofinfrastructure components. More preferably, the data source componentsare server system specific data source components. Even more preferably,each display page has its own corresponding binding engine.

[0029] Preferably also, the individual data source components are sharedby more than one binding engine.

[0030] In a preferred form, the display page acts as a container for thepage elements that make up the display page and provides the primaryuser interface thread of execution. More preferably, the page elementsinclude any one or more element that can be included in an HTML file.More preferably, the page elements include one or more of:

[0031] ActiveX controls;

[0032] VML graphics elements;

[0033] HTML elements;

[0034] HTML scriptlets; and

[0035] Java Applets.

[0036] Preferably, the display page is constructed using a mixture ofstandard HTML and XML tags. More preferably, the HTML describespresentation aspects of the display page—that is the page elements—whilethe XML tags describe what data is required for the page and how thatdata is to be applied to the page. Even more preferably, theinfrastructure components assist with the parsing of the XML content ofthe display page, the delivery of data to the display page and theinitiation of server commands from display page elements.

[0037] In a preferred form, at run time, the display page appears as aninstance of a standard Document Object Model (DOM). More preferably, theDOM is the standard for the industry to which the HMI is applied.

[0038] Preferably, the DOM provides the destination for data provided bythe binding engine. More preferably, the DOM further provides the basisfor the display page scripting environment.

[0039] Preferably also, the display pages are capable of beingencapsulated and re-used as encapsulated displays. More preferably, theencapsulation includes the parameterisation of any data references inthe display page and the addition of properties, methods and events thatallow the encapsulated display to act as a fully fledged component. Evenmore preferably, the encapsulated displays are embeddable. Morepreferably still, the encapsulated displays are linked into containingdisplay pages.

[0040] Preferably, the display page is HTML based.

[0041] In a preferred form, the data source manager manages a pluralityof server system specific data source components that encapsulate thedetails of delivering data to and from particular server systems. Morepreferably, each data source component presents data from a serversystem in the form of a hierarchical object model. Even more preferably,the data source manager pulls the separate data source component objectmodels together into a unified data source object model (DSOM) that isused as the source of data for the binding engine.

[0042] Preferably also, the data source components are informed of thedata requirements for a particular display page by means of a datasource definition that is stored as part of an HTML/XML display pagefile.

[0043] In a preferred form, the server systems include one or more of avariety of different server system, a small subset of which includes theserver systems provided by Honeywell Limited and that are known as:

[0044] Plantscape;

[0045] Enterprise Buildings Integrator;

[0046] TPS;

[0047] TPA;

[0048] QCS;

[0049] Uniformance;

[0050] OPC; and

[0051] HCI.

[0052] Preferably, the data binding engine takes the data provided bythe data source object model and applies it to the display page. Morepreferably, the data binding engine takes the data provided by the datasource object model and applies it to the display page in a way definedby binding definitions contained in the HTML/L display page. Even morepreferably, each display element that requires data has an associatedbinding definition that defines what data is required for the elementand how it is to be applied to the element.

[0053] Preferably also, the data binding engine is able to bind data toany property of the DOM. More preferably, the DOM includes the bodyelement and any container elements that are used to organise otherelements on the display page. More preferably, the binding engine usestransformations to perform the transfer of data from the data sourceobject model to the display page. Even more preferably, thetransformations transfer the data directly from the data source objectmodel to the display page. It is also preferred that the transformationstransforms the data as they transfer the data.

[0054] In a preferred form, the transformations include user written“OnDataChange” scripts and data driven page element “dynamics” such asrotation, path animation and break point animation. More preferably, thetransformations are binary components. Even more preferably, thetransformations are written using an XML syntax and script code.

[0055] In a preferred form, the binding engine executes in an apartmentmanaged by the data source manager and transfers data from the datasource object model to the display page in a very efficient manner.

[0056] The preferred embodiments of the invention provide an operatorframework built around MSHTML to provide the functionality specific tothe needs of an industrial control system. Additionally, it has beenfound that these embodiments, using MSHTML as the underlying renderingengine, provide a flexible, extensible architecture for the provision ofreal-time process data to a state-of-the-art user interface. That is,the preferred embodiments make use of synergies that are possible fromthe interaction between the operator framework and the rendering engine.Again, while the embodiments make use of the MSHTML browser software,other browser techniques would be equally applicable.

BRIEF DESCRIPTION OF THE DRAWINGS

[0057]FIG. 1 is a schematic overview of the architecture according tothe invention;

[0058]FIG. 2 is a schematic representation of an operator runtimeenvironment of one embodiment of the invention;

[0059]FIG. 3 is a schematic overview of the display authoring that isutilised in preferred embodiments of the invention;

[0060]FIG. 4 is a schematic view of the authoring environment providedby one embodiment of the invention;

[0061]FIG. 5 is a schematic view of the PlantScape implementationscenario provided by an embodiment of the invention;

[0062]FIG. 6 is a schematic view of the TPS implementation scenarioprovided by an embodiment of the invention;

[0063]FIG. 7 is a schematic view of the TPS wearable computer remoteclient scenario provided by an embodiment of the invention;

[0064]FIG. 8 is a schematic view of the HiSpec implementation scenarioprovided by an embodiment of the invention;

[0065]FIG. 9 is a schematic view of the TPA implementation scenarioprovided by an embodiment of the invention;

[0066]FIG. 10 is a schematic view of the reuse of configurationcomponents provided by an embodiment of the invention;

[0067]FIG. 11 is a schematic view of the seamless transition betweensystems provided by an embodiment of the invention;

[0068]FIG. 12 is a schematic view of the general arrangement of thesecomponents in the architecture of a preferred embodiment of theinvention;

[0069]FIG. 13 is a schematic view of a data source manager as sharedresource within an embodiment of the invention;

[0070]FIG. 14 is a schematic view of the display page structured used inan embodiment of the invention;

[0071]FIG. 15 is a schematic representation of the data sourcearchitecture used in a preferred embodiment of the invention;

[0072]FIG. 16 is a schematic view of a data source used in an embodimentof the invention and which includes several data references;

[0073]FIG. 17 is a schematic view of a data source used in an embodimentof the invention and which includes hierarchical data references;

[0074]FIG. 18 is a schematic view of the relationship between the datasource manager, the data binding engine and the data source;

[0075]FIG. 19 is a schematic view of the relationship between a datareference that exposes a property, an event and a rowset to a bindingobject which is part of the Hendrix data binding architecture;

[0076]FIG. 20 illustrates the broad components in the Hendrix databinding architecture;

[0077]FIG. 21 is a schematic representation of a “thin client, remoteserver” system provided by an embodiment of the invention;

[0078]FIG. 22 is a schematic representation of a “thin client, singlenode” system provided by an embodiment of the invention;

[0079]FIG. 23 is a schematic representation of a “very thin client,distinct middle tier” system provided by an embodiment of the invention;

[0080]FIG. 24 is a schematic representation of a “very thin client,middle tier” system provided by an embodiment of the invention;

[0081]FIG. 25 is a schematic representation of the binding to the globaldata repository used by an embodiment of the invention;

[0082]FIG. 26 schematically illustrates the sequence of events upon pagecallup;

[0083]FIG. 27 schematically illustrates the general arrangement of theHendrix data source architecture;

[0084]FIG. 28 schematically illustrates the components that constitute adata source, the main COM interfaces they implement and the mainrelationships they have with other parts of the Hendrix architecture.

[0085]FIG. 29 schematically illustrates the typical data source statesand the methods that cause transitions between those states when a datasource is being used to provide data to a run time UI framework;

[0086]FIG. 30 is a UML sequence diagram that illustrates the basicoperation of a Hendrix data source at run time;

[0087]FIG. 31 schematically illustrates the typical data source statesand the methods that cause transitions between those states when a datasource is being used by the Hendrix display builder;

[0088]FIG. 32 is a UML sequence diagram that describes a build modesequence of events in which a new data source is created and configuredto have a simple data object model consisting of a root data objectcontaining one child data object.

[0089]FIGS. 33 and 34 are a schematic representation of the variouscomponents used in the Hendrix runtime environment;

[0090]FIG. 35 is a schematic representation of the framework bindingused in an embodiment of the Hendrix architecture; and

[0091]FIG. 36 is an illustration of some Windows user interface elementsin a Windowless control.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0092] Glossary of Terms

[0093] ActiveX control: a reusable software component exposing itsfunctionality through COM interfaces. ActiveX controls cannot be runalone and must be loaded into a control container such as MicrosoftInternet Explorer.

[0094] DHTML: Dynamic HTML.

[0095] DOM: Document Object Model. Industry-standard object model forHTML scripting.

[0096] Hendrix: The trademark used to identify the common architecturefor the HMI systems developed by Honeywell Limited and which is appliedto the embodiments of the invention described in this specification andmarketed by Honeywell Limited and its associated entities.

[0097] HMI: Human-machine interface.

[0098] HSC: Honeywell Software Center.

[0099] HTML: Hyper-text Markup Language.

[0100] MSHTML: Microsoft-supplied HTML rendering-engine component.

[0101] WWW: World-wide web.

[0102] XML: Extensible Markup Language.

[0103] Binding A particular mapping from a binding source to a bindingtarget.

[0104] Transformation A component supplied to the binding engine totransform data as it is transferred from the data source object model tothe display page.

[0105] Binding Definition The definition of how to map data from thedata source object model on to the DOM. It is a collection of individualbindings.

[0106] Binding Engine The component that maps data from a binding sourceon to a binding target.

[0107] CLSID Class ID Unique identifier for a COM object.

[0108] COM Component Object Model. Microsoft-defined standard for binaryinteroperability of components.

[0109] CSS Cascading Style Sheet.

[0110] Data Reference A hierarchical name that refers to an object orproperty in the data source object model.

[0111] Data Source A server system specific component that communicateswith the server system and provides the data source object model to thebinding engine.

[0112] Data Source Connector The server system specific component on thedisplay page that connects the display page to the data source manager.

[0113] Data Source Definition The server system specific definition ofthe data required by the display page. This definition is understood bythe data source and implicitly defines the shape and size of the datasource object model.

[0114] Data Source Object Model An Automation object model containingdata delivered from the server system. It is the source of data for thebinding engine.

[0115] Data Source Manager The component that coordinates the activityof the data source components and provides the execution environment forthe binding engine.

[0116] Display Page An HTML page that contains a data source connectorand one or more page elements.

[0117] DTD Document Type Definition—used by an XML parser to validatethat the structure of an XML document.

[0118] HTA Hypertext Application—means of constructing a standaloneapplication from a single HTML file.

[0119] IE5: Microsoft Internet Explorer 5.0.

[0120] Operator Framework: A user interface framework that allows anoperator to interact efficiently and directly with the server system.

[0121] Page Element: An element in the display page that has propertiesthat can act as binding targets. (includes ActiveX Controls, HTMLelements).

[0122] Server System: A Honeywell system that is the ultimate source ofdata for a display page. These include PlantScape, TPS, OPC servers etc.

[0123] VML Vector Markup Language—Microsoft's proposal for a standardvector graphics format for the Web.

[0124] W3C: World-wide Web Consortium.

[0125] XML Scriptlet: Method used to build small, flexible COM objectsthrough a combination of XML and script code. A scriptlet may be thoughtof as a COM object, complete with properties, methods, and thecapability of firing events.

[0126] APP: Asynchronous Pluggable Protocol.

[0127] BHO: Browser Helper Object.

[0128] DSM: Data source manager.

[0129] MFC Microsoft Foundation Classes. This is a C++ class librarymainly used for creating WIN32 applications and can be used for creatingActiveX controls.

[0130] ROT Running object table.

[0131] Server System: A Honeywell system that is the ultimate source ofdata for a display page. These include PlantScape, TPS, OPC servers etc.

[0132] VB: Microsoft Visual Basic.

[0133] Introduction

[0134] Some preferred embodiments of the various aspects of the presentinvention are described in Australian provisional patent application noPQ8087 that was filed on Jun. 9, 2000. The disclosure in thatapplication is incorporated herein by way of cross-reference.

[0135] It should be noted that the applicant's code-name for theembodiments of the present invention is “Hendrix”, and this code-nametherefore appears throughout the provisional specification referred toabove. While the same name is used in this specification, for thepurposes of convenience and consistency, it is not intended that theinvention be limited to any system having a particular trade- orcode-name.

[0136] Appendices A to E in the provisional application disclose thedetail of various preferred embodiments of the present invention. Itwill be appreciated that the various discussions of developmentrequirements and the like should be taken in the context of specificissues related to particular products supplied by the applicant, as wellas being concerned with specific embodiments presently envisaged by theapplicant. Accordingly, the information in the appendices should be readas exemplary, and not restrictive of the broadest scope of the inventionas described and defined in the earlier part of the provisionalspecification.

[0137] To fulfil the requirements of an industrial control userinterface the preferred embodiments have been developed on the basis ofthe Hendrix architecture. In a broad form, it is a flexible, extensiblearchitecture for the provision of real-time process data to astate-of-the-art user interface, using MSHTML as the underlyingrendering engine.

[0138] The Hendrix architecture provides a user interface that is suitedto the demands and challenges of the next decade and which is designedto harness key industry standard technologies in an open, adaptable,architecture that facilitates the technological convergence of disparateHMI products. Some important technical features of the Hendrixarchitecture, as exemplified in the preferred embodiments, follow.

[0139] Open display page architecture—the Hendrix architecture separatesthe provision of data and server specific user interactions from theimplementation of individual page elements. The only real assumptionmade about a page element is that it is part of the HTML display pageand accessible via the Document Object Model.

[0140] The provision of data to page elements and the association ofserver specific user interactions with page elements is handled by theHendrix architecture. This has the important effect of widening the setof HMI page elements to include anything that can appear in an HTMLpage.

[0141] A further effect of this architecture is that Honeywell pageelements are more easily reused in contexts outside of the Honeywell HMIfor which they were originally conceived by virtue of the fact that theydo not include any server specific implementation. These contextsinclude, for example, other Honeywell HMIs and non-Honeywellapplications.

[0142] Choice of runtime user environments—the architecture offers achoice of runtime user environments, reflecting the need for bothcontrolled and casual access to process data. The first environment is arobust, secure operator environment, satisfying the distinctiverequirements of industrial control user interfaces. The second is a webbrowser environment in which the user treats display pages as they wouldany other web page. Both environments utilize commodity third-partyrendering engines to display process data.

[0143] Open, extensible file format—the Hendrix architecture centres ona standards-based file format, using HTML as its foundation. The fileformat conforms completely to HTML standards, allowing display pages tobe rendered by a third-party browser. In addition, the ubiquitous natureof the file format allows it to be edited in third party editing tools,in order to apply specialised functionality to display pages, such ascomplex path animation.

[0144] Component-based architecture—the architecture is entirelycomponent-based. It consists of both common components reusable by allHendrix implementations, and server-specific components developed aspart of each Hendrix implementation.

[0145] Data delivery from multiple sources—the architecture is designedto accommodate the delivery of data from multiple Honeywell and otherserver systems to a single display.

[0146] Single authoring tool, customisable for specific server needs—thearchitecture does not dictate how display pages are authored, providedthey comply with the Hendrix file format standard. In the long term, andwith the development of third-party tools, those tools should besufficiently customisable to render them appropriate to this role. Inthe short-term, however, the preferred embodiments rely upon thespecific requirements of Honeywell industrial control systems andrequire a proprietary authoring tool. This tool utilises commoditythird-party HTML editing components where appropriate. It is alsoextensible and customisable, such that it can meet the requirements ofeach server for which Hendrix is implemented.

[0147] These features are schematically represented in FIG. 1. Note thatthis figure does not show all components of the Hendrix architecture andis intended to only provide an overview. Issues such as the binding ofdata from the server data source to HTML data, and the actual deliveryof data, are discussed elsewhere in this specification.

[0148] It is worth noting that the architecture does not necessarilydictate that all servers be capable of supplying remote data to theircorresponding data sources. Some embodiments include one or more serversthat satisfy themselves with server and middle tier (the data sourcemanager and components) on a single machine. It will be appreciated thatthese embodiments still fall within the broader Hendrix architecture.Furthermore, the architecture provides, in some embodiments, remotingfacilities to those components which require it.

[0149] The preferred embodiments are designed to provide users with twoways to view and control plant information: the operator environment,designed primarily for security and reliability, and the web browserenvironment, where universal, flexible, secure data access is the primeconcern. The operator environment is aimed primarily at operators, andis intended to provide a framework tuned to their needs, as follows:

[0150] Framework screen artifacts (menus, toolbars, command zone, alarmzone, etc.) are specific to the server system to which the framework isconnected.

[0151] Page navigation is simple and name-based (i.e. full URLs are notrequired for page navigation).

[0152] Provides explicit control of the connection to the server, ableto specify screen update rates, connection types, and so on.

[0153] Guaranteed view of data via persistent alarm line and statusline, if required.

[0154] Robust in the face of page failure badly-behaved controls cannotcompromise the operator framework.

[0155] Fast automatic fail over in redundant systems.

[0156] Able to be tailored to restrict operator's capabilities (e.g.prevent desktop access, prevent shutdown, full screen lock, SafeView,operator keyboard, etc).

[0157] Secure access to control of process parameters.

[0158] The browser environment is aimed primarily at managers, engineersand process analysts, and is intended to provide a more regular webexperience:

[0159] Navigation is via the normal hyperlinking mechanism, that is,fall URLs are required for page navigation.

[0160] Connections to servers are implicitly created by “surfing” to aserver. Connections use default parameters for things like update rates,connection types, and so on.

[0161] A user has the ability to easily “surf” from system to system.

[0162] A minimal user interface is, in some embodiments,provided—depending on the system—for issuing commands. This userinterface is not persistent and comes and goes with the page.

[0163] Server connections are cached (for a limited time) so thatsecurity levels are able to be maintained across pages.

[0164] Page URLs are selectively saved in browser favourites.

[0165] Menu and toolbars are the browser's menu and toolbars.

[0166] Controls on pages facilitate the control of plant data, as wellas supplying context menus for issuing commands.

[0167] Fail over is not automatic in redundant systems

[0168] The operator runtime environment, in the context of the Hendrixarchitecture, takes many forms in the different embodiments. These formsdepend on the specific market and user requirements of each server type.For example, in one embodiment the runtime environment for one serverconsist of a single framework, complete with menus, toolbar and alarmzone. However, for another server it is a collection of display pages,organized on the screen through the use of a desktop managementframework (e.g. SafeView). It is important to point out that in terms ofthe Hendrix architecture, these frameworks are identical. Data andcommands are supplied to and from the framework in an identical manner,and display page management is the same. A thin layer differentiates theframeworks for different markets, but both systems fit into the Hendrixconcept of the “operator framework”. By way of example, one embodimentof the invention provides an operator runtime environment as illustratedin FIG. 2. This is a PlantScape Hendrix implementation. However, inother embodiments use is not necessarily made of a PlantScape controlbut, rather, another Hendrix-compliant system. In this way Hendrixinherently provides a level of interoperability and convergence amongstHoneywell HMIs. Note also that there is a distinction between thebehaviour of Hendrix-compliant Honeywell controls and third-partycontrols. While these third-party controls are fully integrated into theHendrix environment, they often do not possess some of the advancedfunctionality of Honeywell controls, such as quality indication. Thisadditional functionality is provided by the architecture of theinvention, in that appropriate configuration Hendrix supplied controlsis undertaken to complement the existing third party controls.

[0169] In other embodiments use is made of an alternative operatorruntime environment, consisting of multiple display windows, positionedon screen through the use of desktop management software. Importantlyboth these runtime frameworks are equally valid Hendrix implementations.In fact, the invention was designed with alternative runtime frameworksin mind, as it recognizes that different market requirements requiredifferent user interface frameworks for different server products. Thisis one of the strengths of invention—that is allows the same underlyingarchitecture to be used to produce extremely flexible, market-specific,user interfaces. This flexibility extends all the way to the web browserenvironment. In a Hendrix-based system, the web browser environment isable to display the same pages as those shown in, say, FIG. 2, with livedata updates. The preferred embodiments thus deliver the ability to viewprocess data in a web browser.

[0170]FIG. 3 illustrates an overview of the display authoring that isutilised by the invention. The key points to note are:

[0171] 1. Displays are authored in a single, common authoring tool, andsaved as standard HTML files. The definitions for the retrieval of datafrom various servers are saved in the file by the authoring tool.

[0172] 2. Users, where enabled, have the ability to add functionality todisplays using commodity third-party HTML authoring packages.

[0173] 3. The display is then viewed, in either an operator environmentor in a web browser. In both environments, the display behaves the same,with live data updates from the servers of interest.

[0174] 4. The data source manager—refer to FIG. 1—throughserver-specific components, manages the real-time retrieval of data fromthe servers of interest, and supplies this data to the displays on theclient.

[0175] This presumes a single authoring tool, with add-in components,for all systems in the embodiment to allow it to configure data for thevarious systems. In other embodiments, however, more than one authoringtool is used. FIG. 4 illustrates, by way of example, an authoringenvironment that is provided in one of the embodiments of the invention.

[0176] It should be noted from FIG. 4 that the builder requires theability to configure server-specific data access. The Hendrix HMIprogram allows the use of a single builder for industrial HMI products.In some embodiments, this builder is composed of server-specificcomponents which allow this data configuration to take place. Thesecomponents also allow the builder to be aware of issues such as serverredundancy, data definitions, and server connection details.

[0177] The preferred authoring tool is based around commoditythird-party components, such as an HTML rendering engine for trueWYSIWYG functionality. In other embodiments, however, use is made ofcommodity authoring packages that are sufficiently customisable toprovide all the authoring functionality for Hendrix systems, and for theentire authoring tool to be a commodity item.

[0178] FIGS. 5 to 11 illustrate various implementations of the Hendrixarchitecture, and scenarios in which those implementations are used. Itis important to note that these scenarios serve to illustrate the areaof interoperability between systems. This interoperability takes placeon a number of levels:

[0179] At the control level, the interoperability between systemcontrols is an inherit feature of the architecture provided by thepreferred embodiments of the invention. The architecture fully supportsbinding process data to third-party controls, so by inference anyHendrix HMI supports controls from other Hendrix systems. In addition,controls built to be aware of the Hendrix architecture will be evenfurther integrated into any Hendrix-based operator HMI.

[0180] At the runtime level, the architecture fully supports theintegration of data from multiple data sources. Data from multiple HMIsis delivered to a single display page, resulting in excellentinteroperability between systems.

[0181] At the connection level, the ability to establish a connection toa new server “on the fly” means the architecture provides a seamlesstransition between systems for both the casual user and the operator.

[0182] Another important point that is highlighted by the scenarios ofFIGS. 5 to 11 is the degree of commonality between them. The DataBinding process common to all scenarios, for example, is provided by ageneric binding engine component that is useable in any Hendrix HMIsystem. With such a binding engine implemented it will become availableto all Hendrix implementers. Thus the Hendrix architecture delivers oneof the most significant goals of HMI convergence and of component-basedarchitectures in general: software reuse at the binary level.

[0183] It will be apparent to the skilled addressee, from the teachingherein, that there are any number of user scenarios involvinginteroperability between different Hendrix implementations. The mainpoint to make is that such scenarios are possible, and facilitated bythe Hendrix architecture.

[0184] Benefits Provided by the Preferred Embodiments

[0185] The architecture provided by the invention and as manifest in thepreferred embodiments, offers a large number of benefits to the operatorand the designer of the systems. These benefits are at both a strategicand a technological level and can be broadly categorized into five maintypes:

[0186] 1. Benefits arising from the way the embodiments use commoditythird-party technologies.

[0187] 2. Benefits arising from the use of an open, industry-standardfile format.

[0188] 3. Benefits associated with Hendrix data delivery and dataintegration mechanisms.

[0189] 4. Strategic benefits.

[0190] 5. Benefits associated with “future-proofing” the industrialoperator HMI. These five types will be considered in turn and in moredetail below.

[0191] Use of Commodity Third-Party Technologies

[0192] The architecture of the preferred embodiments, the Hendrixarchitecture, relies on commodity third-party technologies for a numberof its core mechanisms. Where appropriate, these technologies andcomponents provide functionality in areas which are not the corebusiness of the system designer. This allows the designer to focus onthe areas where they are able to add the most value, rather than tryingto compete in areas that are not necessarily within their corecompetencies. The benefits offered by these technologies include:

[0193] Casual access to process data via a web browser. This capabilityis important for non-operator users who do not wish, or who are unable,to install fat HMI client software on their machines. An importantaspect of this capability is the ability to view the same display from aprocess environment in a web browser, not just the ability to publishprocess data on the web.

[0194] Unmatched internationalisation features. With the combination ofInternet Explorer 5.0 and Windows 2000, a Hendrix HMI is able to supplyfar richer internationalisation features than those currently availablein existing HMI systems, such as dynamic language switching, changinglanguage mid-line, and rich third-party internationalisation tools.

[0195] State of the art graphics rendering. The rendering engineprovided by MSHTML is one of the best available, functionally morecapable than any existing product, and likely to continue to improve asthe internet expands. Its animation capabilities and ability to renderhighly-demanding images such as 3D graphics, will prove difficult tomatch in the coming decade. This is more of an advantage in anon-console operator environment. The console operator environment is anarea where the elements of the display must be as non-distracting aspossible, allowing for operators to carry out their normalpattern-recognition and action tasks. One example of the application for3D rendering would be visualisation of blast furnace arrays and thedisplaying of hot spots in the furnace in 3D. [Note that “advancedgraphics rendering” should not be seen as limited to such advancedfunctionality as 3D rendering. The rendering capabilities of MSHTMLinclude the ability to render different graphics formats, such as JPGand GIF files, and any future graphics formats that come available.]

[0196] Easy display deployment. Hendrix systems allow leverage to begained from standard deployment mechanisms available to browsers, whichare becoming richer as the industry progresses. An example is the 7/24availability (7 days a week, 24 hours a day) demanded in modern webservers, which now provide advanced display replication capabilities tomeet these demands.

[0197] User-definable operator frameworks. Technologies such asMicrosoft's Hypertext Application (HTA) technology facilitate thedevelopment of user-definable operator frameworks, which areaccommodated within the Hendrix architecture. This capability, whileprimarily intended from use by the designer of the architecture, is insome embodiments also provided to the users or customers of the system.

[0198] Easy generation of displays dynamically. Standard webtechnologies such as Active Server Pages can be used to generatedisplays on the fly. Depending on different requirements such asoperator capabilities (high-contrast displays for some operators, forexample), or daily activities (different displays to reflect differentschedules on an oil pipeline) can result in different displays beingbuilt on the server and sent to the client. Other examples include theability to generate system management displays dynamically usingstandard mechanisms.

[0199] Ability to integrate with standard value-add offerings forinternet products, such as e-mail integration objects, transactioncomponents, and messaging components, that come as standard parts ofstate of the art web server products.

[0200] Industry-Standard File Format

[0201] The preferred embodiments are centred around an open, extensible,industry-standard file format. Particularly, use is made of a fileformat in as standard an HTML representation as possible, thus reapingthe most benefits from the alignment with industry standards. The use ofthis file format brings a number of benefits, including:

[0202] Third-party authoring tool options. The use of a standard fileformat results in multiple options for authoring tools, particularly inthe area of round-tripping displays. Where a designer's standardauthoring tool does not offer the capabilities required by a particularcustomer, such as complex path animation, this functionality is suppliedby editing the Hendrix display page in a third-party HTML editing tool.The ability to edit a designer's display in a third-party authoring tooloffers unprecedented flexibility to the user of the system.

[0203] Leveraging of existing knowledge. Using both an industry-standardscripting model and industry-standard file format means customers areable to gain leverage from the rapidly growing pool of expertise in webauthoring, graphic design, and HTML scripting to produce high-qualityprocess displays. Users of the system provided by the invention are ableto selectively, and as required, use their favourite graphic design teamto design their displays, rather than relying on the overall systemdesigner for their look and feel.

[0204] The use of a common file format facilitates re-use of displaysbetween different systems, thereby helping to protect a user'sintellectual property investment.

[0205] Display pages are machine-searchable and human-readable. Thisaspect of the Hendrix architecture has a number of benefits, including:

[0206] The ability to facilitate automated cataloguing and searching ofdisplays by customer systems, software applications provided by theprovider of the system, and third-party tools.

[0207] Simple text search and replace functionality external to thebuilder itself.

[0208] Configuration management: the text-based nature of the fileformat renders it suitable for use in configuration management systems.

[0209] Custom manufacturing of standard system displays prior toshipping.

[0210] Ability to preserve user additions to the system displays throughthe process of an upgrade—customisations of system displays can bepositioned along the lines of a macro that alters the system displays,rather than modifications that must be performed on each revision of thedisplays.

[0211] Easier conversion to/from industry standard formats (for example,AutoCAD, PowerPoint) into system displays. In many industries, displaysare first created in AutoCAD, and then have to be transformed toproprietary formats. The adoption of HTML/VML as the file format makesthis conversion simple.

[0212] Powerful template mechanism through the use of Cascading StyleSheets (CSS). The CSS mechanism provides users of the embodiments withthe capability to apply style to entire suites of display pages.Examples of this functionality includes:

[0213] Changing background watermark for an entire set of systemdisplays.

[0214] Updating one or more icons used on every display to reflectchanged company logo.

[0215] Choice of colours to reflect particular customer and/or operatorrequirements, applied across the entire set of displays.

[0216] On a ship system, the ability to supply full-colour displays byday, and red-on-black by night.

[0217] Altering displays according to operator requirements, such ascolour blindness.

[0218] Ability to add user-definable structured data to display pages.Current standard for this capability is through the use of XML. A useris in a position to add customer-specific fields that track changes madeto that display. This structured data is usually stored in the file andmade available via scripting. This functionality is immediatelyaccessible by the user simply through the choice of Hendrix file format.With a proprietary format, the system designer or operator would berequired to implement this functionality on a case-by-case basis.

[0219] The industry-standard file format protects customer intellectualproperty against technological change. With a proprietary format, theoperator is responsible for migration and incompatibility issues whennew file formats are adopted. These issues still exist in the case ofHTML, but the user base of this file format is far larger. While theproblem is not completely removed, the risk of inadvertence is reducedas the number of minds made aware of the issue is far larger.

[0220] Additional enhancements to web file format standards aredelivered for free. Examples of this support—which will be handled bythe MSHTML rendering engine—include Scalable Vector Graphics (SVG) fromthe W3C, and Extensible 3D (X3D) from the Web3D Consortium.

[0221] Data Deliver aid Integration

[0222] The Hendrix architecture is designed for rich data integrationcapabilities, which bring with them the following benefits:

[0223] Ability to integrate data from multiple operator or providersystems on a single display.

[0224] Facilitation of remote operation. The capability of remote databinding realises the possibility of a thin-client architecture on everysystem. The Hendrix client is then completely scalable, and suited forenvironments from hand-held PC devices, through to wearable computersproduced by HTC, all the way to workstations and servers. Thearchitecture expands the reach of the user interface like no existingHMI.

[0225] Seamless integration of foreign data sources via the standardHTML data binding mechanism. Information from Oracle, SQL server, oreven structured data in the form of XML is incorporated into the page,as required for the particular application. Foreign data is used in someembodiments to drive some properties of an object on a page, while inother embodiments use is made also of process data. No ActiveX controlsare required for this data binding—it takes place natively within theengine itself—and can be bound directly to HTML elements such as tables.

[0226] Better integration between the operator HMI and other businesssystems. Business systems are undoubtedly moving towards greaterintegration with the web, which brings the Hendrix HMI closer to thosesystems. The inherent web integration of the architecture, along withnative HTML data delivery and data binding, provide a rich means forintegrating business system information—such as order information in amanufacturing facility, or web-based corrective action applications—intothe operator BMI.

[0227] Another related aspect is the trend amongst device manufacturersto provide the ability to configure their devices (such as terminalservers or printers) using web-based user interfaces. The preferredembodiments allow the user to configure all the devices in their systemthrough a single user interface.

[0228] Future-Proofing

[0229] The Hendrix architecture is designed to protect the HMI fromtechnological change, placing it in a good position to weather changesin the future and thus extending its shelf-life. The term “future-proof”is, of course, a misnomer. No product is able to insure itself againstfuture technological change, no matter how advanced it may be, unless itis able to continually evolve with these changes. Some products,however, are better placed to adapt to change, by virtue of theirarchitectures. It is in this area that Hendrix offers its advantages, asexplained below.

[0230] Note also that “future-proofing” has been a promise of previousarchitectures, but in the past has proved to be an elusive goal. Thefuture-proofing offered by the Hendrix architecture is more extensivethan simply the use of the latest software tools, or the introduction ofopen systems. The Hendrix architecture is unique in several areas:

[0231] It uses commodity third-party components (such as MSHTML) toharness the power of technological change that the internet represents.Standards change, new ones arise, and new technologies become availableas the internet develops—and Hendrix is design to grow with them all.New technologies will become available almost by default, and new toolswill offer capabilities beyond the scope of any one organisation'sdevelopment teams.

[0232] An operator or designer of the system of the invention has noneed to develop a world-class ActiveX control container, for example,when one already exists. The Internet Explorer engine is a controlcontainer par excellence, and is guaranteed to adapt to upcomingtechnological developments. For example, Microsoft has alreadydemonstrated the next-generation control capabilities slated for VisualStudio 7 (code-named “Rainier”), featuring unprecedented integrationbetween controls and their container. This functionality is alreadysupported by Internet Explorer 5.0, and would come for free in thearchitecture provided by the preferred embodiments of the invention.

[0233] One way to view this is that whenever Microsoft raisesperformance expectations in its own products, any ActiveX controlcontainer of our own is expected to do the same. By using theircomponents directly, each improvement they make instead turns into adirect benefit for the system operator and, hence the user. There is adirect flow on effect of the technology as extensive redesign is notrequired to incorporate the new features.

[0234] It is component-based, and thus extremely versatile and able toadapt to change. When new system features become available (for the databinding, authoring, or rendering, for example), only the affectedcomponents need to be replaced, not the entire system.

[0235] It adds the operator's value to precisely those areas suited totheir needs, addressing requirements specific to industrial controlsystems, thus ensuring the viability of the operator's products in thelong term. Hendrix implementations are not threatened by new userinterface technologies, but assisted by them. For example, as commodityediting components and tools become available, the operator simply picksup the functionality of the authoring tool, as appropriate. With priorproprietary systems, this option is clearly not available where theequivalent functionality had to be built into the authoring tool by theoperator, usually at a great cost. It is closely coupled with industrystandards—not just Microsoft technologies referred to above—and isdesigned intentionally to be open and extensible. The standards-basednature of the architecture helps protect the architecture, with bodiessuch as the W3C working to ensure that internet development is anincremental and evolutionary process.

[0236] As previously mentioned, no product is future-proof. The Hendrixarchitecture, however, is designed to be far more adaptive to changethan any existing HMI system.

[0237] The Hendrix Architecture Overview

[0238] The Hendrix architecture describes the components andrelationships between them necessary to build a fully functionalindustrial HMI. The architecture provides the infrastructure for the runtime support of HMI display pages and frameworks in which to view,navigate and interact with them.

[0239] The Hendrix architecture is an entirely component-basedarchitecture in which each component in the architecture is a COMobject. This approach means that the architecture is easily partitionedinto standard components that are used in all Hendrix implementationsand server specific components that must be implemented for each serversystem for which the Hendrix architecture will act as an HMI.

[0240] The foundation of the Hendrix architecture is Microsoft's coreHTML rendering component known as MSHTML. This component forms the basisof an increasing number of Microsoft products including InternetExplorer, Outlook Express, Money98, MSDN Library, Microsoft ManagementConsole and others. It takes the form of a reusable COM object that isavailable to independent software vendors, such as Honeywell, for use inthird party products. The latest version of MSHTML, which forms thebasis of Internet Explorer 5, is positioned by Microsoft as anapplication development platform to rival MEC in terms of performanceand stability. In addition, the latest version of MSHTML includes manynew features that are pivotal in making it suitable as a basis for anindustrial HMI architecture such as the Hendrix architecture.

[0241] MSHTML provides the following HMI capabilities in the Hendrixarchitecture: display file parsing and rendering; ActiveX controlhosting; scripting; 2D graphics primitives (VML); and multimedia andanimation services.

[0242] With MSHTML as its foundation, the Hendrix architecture, asimplemented in the preferred embodiments, achieves two broad goals. Thefirst is to add the mechanisms necessary to turn MSHTML into anindustrial HMI. The second is to structure these mechanisms in such away as to facilitate convergence amongst the various operator HMIproducts. By adopting the Hendrix architecture the operator is able toimplement a common HMI framework for its various industrial processcontrol systems which minimise development effort, maximizeinteroperability of components between systems and, importantly, givecustomers a consistent suite of user interface tools with which tooperate and manage their plants.

[0243] To turn MSHTML into an industrial HMI it is necessary to providemechanisms for data delivery, user initiated commands, navigation,robustness and stability. These mechanisms must be available todifferent classes of users in user interface frameworks that reflect theneeds of each class of user. The personnel that operate the system on aday to day basis require a framework with menus, toolbars and guaranteedaccess to alarm and status information. On the other hand, managers ofthe personnel need more casual access along the lines of a regular webbrowsing experience.

[0244] With these mechanisms in place, the Hendrix architecture allowsthe designer and provider of the system to concentrate on adding valueto its HMI in the form of specific display page elements (typicallyActiveX controls) that allow users to more effectively interact with andmanage both their plant processes and the systems used to control them.The preferred embodiments of the invention also make these controls veryeasy to write.

[0245] The three main components in the Hendrix architecture are theMSHTML display page containing a number of display page elements and asmall number of infrastructure components, the Hendrix data sourcemanager which contains a number of server system specific data sourcecomponents and the Hendrix binding engine which transfers data andcommands between the data source components and the display pageelements. FIG. 12 illustrates the general arrangement of thesecomponents.

[0246] The data source manager used in the preferred embodiments is aresource shared by all display pages on the client machine and eachdisplay page has its own binding engine. Data source components are alsoshared by binding engines, although this need not occur in allinstances. FIG. 13 illustrates a data source manager that is used in apreferred embodiment of the invention.

[0247] The MSHTML based display page acts as the container for the pageelements that make up the display and provides the primary userinterface thread of execution. The page elements, in some embodiments,include Honeywell ActiveX controls, third party ActiveX controls, VMLgraphics elements, HTML elements, HTML scriptiets, Java Applets etc. Infact, anything—control, element, or otherwise—that can be included in anHTML file counts as a page element in the Hendrix architecture.

[0248] The display page is constructed using a mixture of standard HTMLand Hendrix specific XML tags. The HTML describes the presentationaspects of the display page (that is, the page elements) while the XMLtags are used to describe what data is required for the page and howthat data is to be applied to the page.

[0249] The display page also contains a small number of Hendrixinfrastructure components that assist with the parsing of the XMLcontent of the display page, the delivery of data to the display pageand the initiation of server commands from display page elements.

[0250] At run time the display page appears as an instance of theindustry standard Document Object Model (DOM). This object modelprovides the destination for data provided by the Hendrix data bindingengine and provides the basis for the display page scriptingenvironment.

[0251] Display pages are preferably encapsulated for reuse. Thisencapsulation includes the parameterisation of any data references inthe display page and the addition of properties, methods and events thatallow the encapsulated display to act as a fully fledged component.Encapsulated displays are usually either embedded or linked intocontaining display pages.

[0252] The data source manager is the component that co-ordinates thedelivery of data from the various server systems to the Hendrixarchitecture. The data source manager manages a series of server systemspecific data source components that encapsulate the details ofdelivering data to and from particular server systems. Data sourcecomponents are required for Plantscape, TPS, TPA, QCS, Uniformance, OPCand HCI. Each data source component presents data from a server systemin the form of a hierarchical object model.

[0253] The data source manager pulls the separate data source componentobject models together into a unified data source object model that isused as the source of data for the Hendrix binding engine.

[0254] The data source components are informed of the data requirementsfor a particular display page by means of a data source definition thatis stored as part of the HTML/XML display page file. The details of thedata source definition is a data source component implementation detail.The data source definition is usually the result of a “pre-binding”mechanism that turns the human readable data references used in thedisplay page into machine readable names that provide for more efficientdelivery of data at run time or it may simply define the extrainformation required to deliver the required data such as update ratesand the like.

[0255] Data source components are used to optionally support indirectdata references where an item in the data source object model is used asa place holder for particular objects in the server system which arespecified at run time. This provides a level of indirection in the datasource that is used to “browse” through objects of the same type.

[0256] The preferred data binding engine takes the data provided by thedata source object model and applies it to the display page. It doesthis in a way defined by binding definitions contained in the HTML/XMLdisplay page. Each display element that requires data has an associatedbinding definition that defines what data is required for the elementand how it is to be applied to the element.

[0257] A key feature of the data binding engine of the preferredembodiments is that it is able to bind data to any property of the DOM.This includes the body element and any container elements that are usedto organise other elements on the display page.

[0258] The architecture of the binding engine is component based anduses “transformations” to perform the transfer of data from the datasource object model to the display page. These transformations allow thetransfer of data directly or transform it some way as they transfer thedata Examples of where transformations are used include user written“OnDataChange” scripts and data driven page element “dynamics” such asrotation, path animation and break point animation. Transformations arepreferably either binary components or written using and XML syntax andscript code.

[0259] The binding engine executes in an apartment managed by the datasource manager and transfers data from the data source object model tothe display page in a very efficient manner.

[0260] Each server system for which the Hendrix architecture is actingas an HMI has its own set of commands that a user may need to invoke.These include commands directed at the process such as “raise” and“lower” or at the server system itself such as “acknowledge alarm” and“point detail”.

[0261] These server specific commands are implemented as methods on theroot object of each server specific data source component. Thesecommands are executed from page based script code or from serverspecific “behaviours” associated with display page elements.

[0262] In addition there are system wide commands that apply acrossserver systems such as commands to log on to the system or changesecurity levels. These commands are implemented as methods on the rootof the unified data source object model provided by the data sourcemanager. Again, these commands are executable from page based scriptcode or from a behaviour associated with display page elements.

[0263] In many circumstances it is necessary to allow users to viewdisplay pages within some framework that makes the task of viewing,navigation and interacting with display pages easier and safer. Examplesinclude the Plantscape Station framework (that provides a menu, toolbar,alarm zone, status zone, message zone and command zone), the SafeView(which provides window management for multiple displays) and the TPAframework (that allows the user to easily navigate between displays).

[0264] The Hendrix architecture itself provides a mechanism forconstructing a user interface framework. This is achieved byconstructing the framework as a series of display pages that manageother display pages. It is easy to construct frameworks that contain theusual user interface elements such as menus, toolbars, status lines aswell as HTML constructs such as framesets. This makes the repertoire ofpossible frameworks very large indeed.

[0265] Hendrix based frameworks in conjunction with SafeView provide aflexible, powerful and safe means of delivering the environments neededby users to more effectively use an HMI.

[0266] At run time a Hendrix display page is an instance of the industrystandard Document Object Model (DOM). The DOM contains instances ofuseful display elements such as ActiveX controls, HTML elements,graphics primitives etc. The DOM is initialised from an HTML file thatspecifies the initial content of the display page and is created by anauthoring tool such as the Honeywell Common Display Builder. An HTMLparser parses the HTML file and initialises the DOM. A rendering enginethen renders the DOM in a window. Hendrix uses Microsoft's MSHTMLcomponent for these functions. FIG. 14 illustrates the generalarrangement of the main display page components.

[0267] Once initialised, the page is updated with data from the Hendrixdata binding engine upon which the HTML rendering engine re-renders thedisplay page so that the user sees the changes to the page (thisre-rendering behaviour is what is commonly known as “Dynamic HTML” orDHTML). The flow of data between the data binding engine and the displaypage is typically bidirectional. Any changes made locally to the displaypage, by the user or by script code, are re-rendered by the renderingengine and propagated back through the data binding engine.

[0268] In addition to the presentation aspects of the display pagedefined using HTML there are Hendrix specific XML tags in the displaypage file that define the details of what data is required by thedisplay page and how to apply that data to the display page.

[0269] The details of what data is required by the display page arecontained in a series of data source definitions. There is one datasource definition for each type of data source component (that is, eachtype of server system) from which data is required for the page. Thedetails of the data source definition are specific to each type of datasource component.

[0270] The details of how to apply the data to the page are contained ina series of binding definitions. There is one binding definition foreach page element that requires data from the server system.

[0271] The display page also contains a data source connector thatestablishes communication with the data source manager. The data sourceconnector also plays an important role in transferring data from thedata binding engine of the preferred embodiment and in providing “nameddata access”.

[0272] The display page contains components that assist with the parsingand processing of the XML portions of the display page file.

[0273] The display page file is completely managed by a common displaybuilder which, in this embodiment is proprietary software developed byHoneywell. This software produces and maintains both the HTML and theXML content of the file.

[0274] The split between the HTML and XML portions of the display pagefile corresponds to a split between the presentation and content aspectsof the display page. Since the presentation aspects of the display pageare expressed in standard HTML, third party tools can manipulate thepresentation to provide functionality not provided by the common displaybuilder. Because third party tools will not understand the XML portionsof the display page file the data source definition and the bindingdefinition will remain opaque to those tools.

[0275] The immediately following description deals with the basicdisplay page HTML/XML file format, while later description discusses thedata source definition and binding definition in detail.

[0276] The following example illustrates a very simple Hendrix displaypage that contains a single page element. <HTML> 1 <xml:namespacens=”urn:schemas-honeywell-com:hendrix” prefix=”HENDRIX”/> 2 <OBJECTID=”Data” CLSID=”...”></OBJECT> 3 <OBJECT ID=”HendrixExtensions”CLSID=”...”></OBJECT> 4 <OBJECT ID=”HendrixExtendedElement” CLSID=”...”></OBJECT> 5 <OBJECT ID=”PlantscapeCommands” CLSID=”...”> </OBJECT><STYLE> 6 HENDRIX♯:* {behavior: url(#HendrixExtensions)} 7 .Hendrix{behavior: url(#HendrixExtendedElement)} 8 .PlantscapeCommands{behavior: url(#PlantscapeCommands)} </STYLE> <BODY> 9 <SPAN ID=”Alpha1”CLASS=”Hendrix; PlantscapeCommands” BINDINGDEF=”Alpha1BindingDef”></SPAN> 10 <HENDRIX:BINDINGDEF ID= ”Alpha1BindingDef”> <DATAID=”DataRef1” REF=”OPC.Modbus.A100.PV”/> <BINDING SOURCE=”DataRef1”TARGET=”PageElement.InnerHTML”/> </HENDRIX:BINDINGDEF> </BODY> 11<HENDRIX:DATASOURCEDEF ID=”OPC”CLSID=”DA943720-8048-11d2-8ED5-000000000000”> <SERVER NAME=”modbus”><GROUP UPDATEPERIOD=”500”> <ITEM NAME=”A100.PV”/> </GROUP> </SERVER></HENDRIX:DATASOURCEDEF> </HTML>

[0277] The file begins with an XML namespace declaration thatestablishes the use of the Hendrix namespace in this file (1). This stepis followed by the data source connector (2) and the two components thatassist with the processing of the XML content of the page (3 and 4) anda component that implements Plantscape command behaviour (5). A STYLEblock is used to associate convenient names with the infrastructurecomponents (6,7 and 8). The body of the display page then contains asingle HTML element (9). This SPAN element has a binding definitionassociated with it (10). This binding definition specifies that the dataitem OPC.Modbus.A100.PV is bound to the InnerHTML property of the SPANelement. Finally, there is a data source definition for the OPC datasource component (11) that specifies the details of how to get the itemA100.PV from the OPC server called Modbus.

[0278] Note that in this example there is only one data sourcedefinition in the file. In other embodiments, where the display pagerequires data from more than one server system, there are data sourcedefinitions for each type of server system.

[0279] The most commonly used categories of display page element areActiveX controls, VML graphics elements and HTML elements. As mentionedelsewhere, the ActiveX controls are either or both of Honeywell or thirdparty controls. VML graphics elements include built in simple shapessuch as rectangles, lines, ellipses, arcs etc or more complex shapetypes. HTML elements include the full suite of normal web page elementssuch as DIV, SPAN, IMAGE, TABLE, INPUT, OPTION, SELECT etc.

[0280] The architecture of the invention, as provided in the preferredembodiments, allows this wide variety of display page elements to betreated equally with respect to supplying data to them from serversystems. This is achieved by the binding engine assuming most of theresponsibility for transferring data from the data source components tothe display page elements. The display page elements simply have tooffer properties to which data can be delivered. A similar situationexists with respect to server and system command behaviours. Commandfunctionality is added to page elements by the Hendrix architecturewithout the behaviour having to be explicitly coded into the elementsthemselves.

[0281] This effective separation of presentation, content and behaviourin the Hendrix architecture means it is easy to write ActiveX controlsthat work well in the Hendrix architecture. Most controls do not need toworry at all about how data is supplied to them or how commandbehaviours are associated with them. The control designer is free toconcentrate on the presentation aspects of the control which makes thetask of designing controls much simpler. This also makes the systemincredibly robust.

[0282] There are, however, a small number of requirements that ActiveXcontrols used as Hendrix page elements must meet to be fully integratedinto the Hendrix architecture. These fall into two main categories:requirements that make the controls “Hendrix compatible” andrequirements that make the controls “Hendrix aware”.

[0283] The first requirement of Hendrix compatible controls is that theyprovide property change notifications if they are to write changedvalues back to the server system. This is because the binding engineuses these notifications to know when to send a new value back to thedata source object model. This corresponds to the properties of theelement being marked as [bindable] in the element's type library.

[0284] A page element property that is bindable may support optimisticbinding or pessimistic binding. Optimistic binding means that theelement will simply notify the binding engine that the property haschanged, after which the binding engine will propagate the new valueback to the binding source in the data source object model. If, for somereason, the value cannot be changed on the server system, for securityreasons perhaps, the data source object model will need to notify thebinding engine that the value has changed back to the previous value andhave the binding engine propagate that value back to the page element.

[0285] In the case of pessimistic binding the page element will ask thebinding engine if the property value can change. The binding engineforwards this request on to the binding source where securityconsiderations etc. can be checked. If the value can be changed the pageelement then changes the value and notifies the binding engine. If apage element supports pessimistic binding its properties will be markedas [bindable, requestedit].

[0286] The Hendrix architecture supports both types of binding. If aproperty of a page element does not support either type of binding itcan only be used for read only data.

[0287] The other requirement of a Hendrix compatible control that allowscomplete integration in the Hendrix architecture is that the control bewindowless so that command behaviours are associated with the element.If the element has a window, for example an ActiveX control that doesnot conform to the OC96 specification, the command behaviour will notreceive user input.

[0288] Note that page elements that do not meet these requirements arestill usable in the Hendrix architecture, but they will suffer from thetwo limitations noted above.

[0289] Hendrix aware controls are controls that know about the Hendrixarchitecture and that use it to their advantage. An example is a trendcontrol that knows how to interact with the data binding engine toaccess more historical data as the user scrolls the trend. Anotherexample is a combobox control that directly request the delivery of itslist only when the user clicks on the control to drop the list down.

[0290] Another important aspect of Hendrix aware controls is that theyare designed with properties that correspond to properties on the serversupplied data source object models so that the binding of data to thecontrol is as direct as possible and hence as efficient as possible.

[0291] In short, Hendrix aware controls are the controls that work bestwith the Hendrix architecture. Non-Hendrix aware controls are stillusable in the preferred embodiments, but may require small amounts ofscript code to effect full integration.

[0292] The Hendrix architecture encapsulates the mechanisms used tocommunicate with a server system at run time. These mechanisms includethe delivery of data to the Hendrix architecture and the routing ofcommands back to the server system.

[0293] A Hendrix data source is a component that encapsulates a serversystem at run time. It consists primarily of data reference objects thatencapsulate the details of delivering particular data items from theserver system. The data references are organised into a data referenceobject model, which is used by the Hendrix data binding architecture asinput. The data reference object model is also accessible by displaypage script code and Hendrix transformations. The data reference objectmodel also provides the means by which commands are routed to the serversystem. Commands are implemented as methods on data references withinthe data reference object model.

[0294] The delivery of data from a server system involves many serversystem specific details. For this reason data sources need to bedeveloped for each type of server system. Even within a single serversystem there may be different types of data items that are delivered indifferent ways which means data reference objects need to be developedfor each type of data item in each server system.

[0295] The data source manager is the Hendrix component responsible forcoordinating the delivery of the data required by display pages. Itmanages both the server system specific data sources and the bindingengine that transfers the data from the data source components to thedisplay page. FIG. 15 illustrates the general arrangement of thesecomponents.

[0296] When a display page is called up, the data source manager acceptsURLs for the data source definitions and binding definitions from thedata source connector on the display page. It parses the data sourcedefinitions and instantiates the necessary data sources. It then passesthe data source definitions to the data sources so that they canconstruct their data reference object models. The data sources then passreferences to their individual object models back to the data sourcemanager which then makes them available to the binding engine togetherwith the binding definitions for the page. The binding engine then bindsthe data references in the data reference object models to the displaypage according to the binding definition. The data sources are theninstructed by the data source manager to begin delivering data.

[0297] A Hendrix data source implements a memory resident hierarchicaldata reference object model. This object model consists data referenceobjects. These data reference objects provide the means by which datafrom the underlying server system is presented to the Hendrixarchitecture.

[0298] A data source appears as in-process COM object to the data sourcemanager. In order for a data source to be usable on a machine other thanthe server system itself it must include a mechanism for populating itsobject model over the network The mechanism to do so is animplementation detail of each data source.

[0299] The main task of a data source is to provide an initialisationservice to the data source manager. This initialisation service allowsthe data source manager to pass a stream containing a data sourcedefinition to the data source. This data source definition contains theinformation necessary for a data source to construct and initialise itsdata reference object model. Once initialised, the data source returnsthe root of its object model to the data source manager.

[0300] The data reference object model is used as input to the Hendrixdata binding engine. However, before the binding engine transfers datato the display page it needs to bind to the data references. It doesthis according to a binding definition associated with the display page.

[0301] Once the data source has been initialised and the binding enginehas bound to its data references, the data source will be started sothat it connects to the server system and begins delivering data to thedata binding engine. The delivery of data is actually performed byindividual data references.

[0302] When the data references are no longer required the data sourceis stopped and the data source closes any connections it has with theserver system. The binding engine then release all data references. Thedata source manager will uninitialise the data source during which thedata source will discard its data reference object model. The datasource manager usually caches a data source in the uninitialised statefor future use.

[0303] There is a one-to-one relationship between display pages and datasources. A data source will only ever be supplying data to a singledisplay page. The one data source manager, however, is able to supplydata to multiple display pages. In this case the data source manager ismanaging multiple data sources for multiple display pages. Thesemultiple data source instances may make use of shared resources forcommunicating with the server system. This sharing of data includes thesharing of physical network connections and the consolidation of datadelivery to avoid the duplicate transmission of data that is common tomultiple display pages. This behaviour is a data source specificimplementation detail.

[0304] A key concept in the Hendrix data delivery mechanism is that ofthe data reference. A data reference is an object that refers to a nameddata item in a server system. A data reference encapsulates the detailsof delivering the data to which it refers from a server system to theHendrix architecture.

[0305] A data reference typically augments the name of the referenceddata item with the additional information required to affect thedelivery of the data item. This additional information includes one ormore of update rates, time intervals for historical data, additionalquery parameters and the like.

[0306] Data references deliver data to the Hendrix architecture viaproperty change notifications, OLE DB rowset notifications and events.

[0307] A data reference has the following basic structural elements:

[0308] 1. An ID by which it is known to the Hendrix architecture.

[0309] 2. An associated name from the server system namespace whichidentifies the data item to which the data reference refers.

[0310] 3. One or more properties, OLE DB rowsets, methods and/or eventsthat represent the referenced data item to the Hendrix architecture.

[0311] 4. A set of properties that define the additional informationrequired for the delivery of the referenced data item (also known asdata delivery properties).

[0312] The ID is a read only property. The data reference ID is largelyan internal name for the data reference and is rarely seen by end users.

[0313] The name is optionally a read/write property.

[0314] Since the ID of the data reference and the name to which itrefers are separate properties, a data reference provides a natural formof indirection. If the associated namespace name is changed at runtime,the data reference then refers to a different data item in the serversystem. This runtime indirection is an optional property of datareferences that is difficult to implement in some cases. If so, it iseasily disabled by simply making the name property read only.

[0315] The set of properties, methods and events that represent the dataitem to the Hendrix architecture (and can be bound to display pageelements) depend on the type of the referenced data item. In many casesa single property that represents the value is all that is necessary.The value property is typically the default property on the datareference. This makes the syntax for accessing the value slightly morecompact.

[0316] A slightly more complex example is provided by data items thathave an associated quality indication In this case, the data referenceincludes a property for the value (the default property) and a propertyfor the quality indicator.

[0317] The data delivery properties are read only or read/writeproperties depending on the capabilities of the server system. Again thespecific set of properties required depends on the server system and thetype of the referenced data item. The data delivery properties includepropertes that control the transmission of data from the server systemsuch as update rates or information that helps to completely identify adata item in cases where a name from a server system namespace is notsufficient.

[0318] The following example further illustrate the basic data referenceconcept and its practical implementation.

[0319] Consider a data reference that refers to an item in a Plantscapeserver called “34FC1234.PV”. The data reference's ID might be ParamRef1and the associated namespace name would be “34FC1234.PV”. FIG. 16illustrates a data source with several data references.

[0320] The Hendrix architecture knows the value of the referenced dataitem as ParamRef1 (or ParamRef1.Value). If the data item includes aquality indication the Hendrix architecture knows it asParamRef1.Quality.

[0321] Script code for changing the namespace, in some embodiments,takes to following form:

[0322] ParamRef1.name=“34FC2222.PV”

[0323] As far as the Hendrix architecture is concerned nothing haschanged, the data reference ParamRef1 is still supplying data, butbehind the scenes it is now getting data from another item in thePlantscape server. Of course, this implies that the new data item in theserver is of the same type as the previously referenced data item sothat the same data reference object is used to reference it.

[0324] Data references are also organized in a hierarchy if this betterreflects the structure of server system data. A hierarchicalorganization allows multilevel indirection to occur.

[0325] The following example shows how hierarchical data references inan LCN data source provide multilevel indirection. Consider two datareferences that refer to different parameters of the same tag in an LCNsystem. ParamRef1 refers to “A100.PV” and ParamRef2 refers to “A100.SP”.FIG. 17 illustrates this example.

[0326] Where the desired effect is to change both of these datareferences to look at the same parameters of another tag, “A200”, thenamespace name of both data references could be changed as above torefer to “A200.PV” and “A200.SP” respectively. Alternatively, and asimplemented in some embodiments, a separate data reference is used forthe tag name called TagRef1 that initially refers to “A100” withParamRef1 and ParamRef2 now referring to “PV” and “SP” respectively. TheHendrix architecture then knows “A100.PV” and “A100.SP” asTagRef1.ParamRef1 and TagRef1.ParamRef2.

[0327] The following script code is all that would be required to changethe references from “A100.PV” and “A100.SP” to “A200.PV” and “A200.SP”.

[0328] TagRef1.name=“A200”

[0329] It is up to the data source to make sure that all data referencesbelow TagRef1 now refer to the correct parameters in the server system.

[0330] Another common application of hierarchical data references iswhen a data source provides data from multiple server systemssimultaneously. An example of this is an OPC data source. In this case adata reference refers to the server and data references that refer tothe items within the server would appear as children of the serverreference. The associated namespace name for the server reference is,for example, the machine name of the OPC server and the data deliveryproperties for the server reference includes, for example, informationrequired to connect to the server such as the ProgID or CLSID of the OPCserver.

[0331] Support for hierarchical data references is entirely optional andadds to the complexity of the data source implementation.

[0332] Data references are preferably organized into collections.Collections occur at any level in a hierarchical data reference.

[0333] In some embodiments, the data references have predefinedsub-objects. An example is a server system that supplies all relevantparameters for a given named tag (eg A100). If a data reference with theID DataRef1 refers to “A100” then the Hendrix architecture knows itsparameters simply as DataRef1.PV, DataRef1.SP etc without the need forexplicit data references for each parameter.

[0334] Data references that are appear as predefined sub-objects arereferred to as implicit data references.

[0335] As noted above, data references expose the data they refer to asproperties. The basic property data types supported are VARIANT and OLEDB Rowset.

[0336] The following VARIANT types are supported:

[0337] VT_UI1, VT_I2, VT_I4,VT_R4, VT_R8, VT_CY, VT_DATE, VT_BSTR,VT_VARIANT VT_BOOL, VT_NULL, VT_ERROR

[0338] Safe arrays of these types are also supported (VT_ARRAY|*).

[0339] In other embodiments of the invention a data reference alsoexposes data to the binding engine in the form of an OLE DB rowset. Therowset is exposed as a sub-object of the data reference. In this casethe information required to establish the OLE DB session and create therowset is usually part of the data delivery properties of the datareference.

[0340] Further embodiments have data references that include datadelivery properties that allow finer control over the reference thatthan provided by simply changing the associated name. An example is adata reference that refers to a single element in an array. In such anembodiment, the data reference has an index associated with it inaddition to namespace name. Consider a data reference with the IDArrayRef1 that refers to “Analyzer1.ConcentrationData”. To fullyidentify a single element within the array an index is also required.The data reference definition for the reference includes an initialvalue for the index and it is subsequently changed using script code asfollows.

[0341] ArrayRef1.Index=2

[0342] A further example of a more complex data reference is one thatrefers to data in a relational database that requires a number of SQLquery parameters to fully specify the reference.

[0343] Data references exist to supply data to the data binding engine.They do this through property change notifications. As the data referredto by a data reference changes in the server system it is delivered tothe data reference using a server system specific mechanism. The datareference then notifies the binding engine that a data referenceproperty has changed. The notification mechanism allows the datareference to pass the changed data to the binding engine as part of thenotification which means that it is not necessary for the data referenceto cache the data internally. There are, however, some server systems inwhich it is advantageous to cache the data within the data reference.

[0344] In addition to providing property change notifications a datareference is used, in some embodiments, to also fire events. Theseevents are mapped on to methods on display page elements or consumed bythe binding engine.

[0345] Similarly, data references are also used, in some embodiments, toalso expose methods. These methods are typically commands associatedwith a particular type of data reference. For example, a data referencethat provides access to a segment of an array in a server systemprovides commands (methods) that allow the segment to be scrolled alongthe length of the underlying array.

[0346] Data references are accessible from display page script code viathe root of the data source object or via display page elements to whichthey are bound. Accessing the root of the data reference object modelcan be done as follows

[0347] Data.data_source_namespace_identifier

[0348] Where Data is the SGML ID of the display page's data sourceconnector and data_source_namespace_identifier identifies the datasource. A more detailed example is as follows:

[0349] Data.OPC.ServerRef1.name=“Refinery2”

[0350] Accessing a data reference via a display page element is done asfollows:

[0351] Ref=Alpha1.DataRefs(index)

[0352] Where index is either the ID of the data reference or theassociated name. The IDs of bound data references are searched first. Ifthe associated name is associated with more than one bound datareference, the first is returned. If the display element is bound to ahierarchical data reference then the lowest level data reference isreturned.

[0353] Each display page has associated with it a series of data sourcedefinitions, one for each data source from which data is required. Eachdata source definition contains the data source specific informationrequired to construct a data reference object model that contains thedata references required by the display page.

[0354] The data source definitions are stored in an XML document. Eachdata source definition is enclosed in a HENDRIX:DATASOURCE element. Thiselement has attributes that identify the namespace with which the datasource is associated and the CLSID of the data source component. Thecontent of the DATASOURCE element is a data source specific detail. At aminimum it contains information on how to construct data referenceobjects that reference the required namespace names.

[0355] The format of a data source definition is assumed to be validXML. If it is not valid XML it must be enclosed in a CDATA section.

[0356] The following example illustrates a data source definition for anOPC data source (CLSIDs elided for clarity).   <HENDRIX:DATASOURCENAMESPACE=”OPC”   CLSID=”DA943720- 8048-11d2-8ED5-000000000000”      CONNECTSTRING=”SERVER=OPCX...”>     <SERVER NAME=”Modbus”>      <GROUP UPDATERATE=”5000”>         <!-- the following correspondsto a reference to ”OPC://Modbus.34FC1234.PV” -->         <DATAREFID=”DataRef1”         NAME=”34FC1234.PV”/>       </GROUP>     </SERVER>  </HENDRIX:DATASOURCE>

[0357] The above example illustrates that the organization of the datasource definition is dependent on the server system that the data sourceencapsulates. In this case the organization is by OPC server and group.

[0358] The following example shows how a data source definition thatincludes binary data might look.   <HENDRIX:DATASOURCE NAMESPACE=”LCN”  CLSID=”DA943721- 8048-11d2-8ED5-000000000000”>    <![CDATA[FE12345AB65C98AFABE192F87E2A26C...      78C67BAE451F536D]]>   </HENDRIX:DATASOURCE>

[0359] In this case the organization is not obvious because thedefinition is an opaque blob of binary data. All that matters is thatthis definition is meaningful to the LCN data source.

[0360] If a data source supports hierarchical data references, the datasource definition will need to include the hierarchical relationshipsbetween data references.

[0361] As discussed above, data source definitions define the set ofdata references required by a display page. At run time, the entire datasource definition is loaded into a data source so that the data sourceis able to construct the required data reference object model.

[0362] During the display building process data source definitions needto be updated as the user adds and removes references to data in thedisplay page. Since the user deals primarily with server systemnamespace names rather than data reference IDs, an important design timetask is to take a server system namespace name and add a data referenceof the correct type to the data source definition. These namespace namescome from either the Hendrix namespace browser or from direct userinput.

[0363] This task is handled by a design time component known as a “datasource definition editor”. A data source definition editor is able toadd and remove data references from a data source definition. They areused by the common display builder. They also supply property pages thatare used in the common display builder to allow the user to configurethe data delivery properties for a data reference.

[0364] A data source is an in-process COM object that implements theIHendrixDataSource interface. This interface allows the data sourcemanager to initialise, start and stop the data source. The main purposeof the data source is provide a data reference object model to the databinding engine. This data reference object model consists of a hierarchyof data reference objects and collections of data reference objects. Infact the data reference object model is a standard automation objectmodel, with the exception that a more efficient form of connection pointmechanism is used.

[0365] The data source is initialised with a data source definition thatinforms the data source of what data is required from the server system.Once initialised, the data source is transitioned to the running state,in which it delivers data to the data binding engine via the datareference objects.

[0366] The data source also exerts some high level control over thetransmission of data from the data binding engine to the display page.This is achieved via the IHendrixBindingEngineCache interface. This isuseful when a data source wants to ensure that an update is deliveredimmediately to the display page, rather than cached for later deliveryas part of a larger update packet. FIG. 18 shows the relationshipbetween the data source manager, data binding engine and data source.

[0367] A data reference is a COM object that exposes the IDispatchinterface and supports property change notifications. OLE DB rowsets areexposed as sub-objects of the data reference. This allows the datareference to expose more than one rowset. Hierarchical data referencesand collections of data references are implemented using sub-objects inthe normal OLE Automation fashion.

[0368] A data reference notifies the data binding engine of changes toproperties via the IHendrixNotify interface provided by the bindingengine. Data references that fire events do this via IDispatch.

[0369] OLE DB Rowsets expose IRowset (and related interfaces such asIAccessor, IConnectionPointContainer etc). An OLE DB rowset notifies thedata binding engine of changes to the rowset via the IRowsetNotifyinterface provided by the binding engine. A rowset data reference, insome embodiments, also exposes IDispatch if it occurs within ahierarchical data reference in order to provide access the lower levelsof the reference.

[0370]FIG. 19 illustrates the relationship between a data reference thatexposes a property, an event and a rowset to a binding object which ispart of the Hendrix data binding architecture.

[0371] The previous description has gone to the presentation and contentaspects of the Hendrix architecture, that is the HTML/XML display pageand the data source architecture. The addressee's attention is nowdirected toward the mechanism that maps the content onto thepresentation. The data binding architecture is a key element that givesthe Hendrix architecture much of its flexibility and power. Moreparticularly, the data binding architecture provides a means of bindingdata to virtually anything on the display page in a very efficientmanner. It also provides a very flexible data transfer mechanism thataccommodates the transformation, combination and filtering of dataprovided by the Hendrix data source architecture.

[0372] MSHTML provides its own data binding mechanism for binding datafrom OLE-DB data sources to HTML elements and ActiveX controls. Thismechanism is deficient in that it expects data in a tabular form, whichis inappropriate for much of the data required in an Industrial HMI, andit only binds data to a limited set of properties in the DOM. For thesereasons, the Hendrix architecture includes its own data bindingmechanism.

[0373] The MSHTML data binding mechanism does, however, provide goodsupport for binding to HTML tables. For this reason an interface to theMSHTML data binding mechanism for tabular data from server systems isalso available.

[0374] The Hendrix data binding architecture is based on a highperformance binding engine that maps properties from the data referenceobject model on to properties of DOM. It does this in an entirelygeneral way so that any property in the data reference object model ismapped on to any property in the DOM. FIG. 20 illustrates the broadcomponents in the Hendrix data binding architecture.

[0375] The binding engine uses a series of binding definitions suppliedfrom the HTML/XML display file that defines how to map data from datareference object models to the display page. The binding engine movesdata between properties in the data reference object model and thedisplay page in response to changes in those properties. It can movedata in either direction so that data changed in the display ispropagated back to the data reference object model and then on to thevarious server systems. A specialised form of data binding is OLE DBrowset binding where a rowset exposed in the data reference object modelis mapped on to either a rowset or an OLE DB Simple Provider in thedisplay page for binding to HTML tables.

[0376] The binding engine also map events in the data reference objectmodel to methods in the display page and vice versa. Binding definitionsare discussed in more detail below.

[0377] The internal architecture of the binding engine is componentised.The transfer of data from the data reference object model to the displaypage is made through tranformations. The simplest form of transformationis one that directly transfers a property or event from the datareference object model to the display page. More complex transformationsinclude a transformation of the data in some way, or use severalproperties from the data reference object model to derive a value thatis then transferred to the display page. Transformations are selectivelychained together to form more complex transformations. Transformationsare either supplied by end users, consultants to those users, or theprovider of the system.

[0378] The binding engine executes in an apartment managed by the datasource manager while the display page executes in its own apartment. Anychanges to data in the data reference object model are detected by thebinding engine which then transfers the data to the data sourceconnector in the display page which applies the updates to the displaypage elements. The binding engine maintains an internal cache of updatesthat are transferred to the data source connector in batches to minimizeinter-apartment round-trips and minimize display page redrawing. Thisbatching of updates only occurs for transfers from the data referenceobject model to the DOM. Transfers in the other direction are alwaysimmediate. An important consequence of this architecture is that themain display page's thread's involvement in the handling of incomingdata is minimized making it more responsive to user interaction.

[0379] Binding definitions are used to tell the binding engine how tomap data from the data reference object model on to the display page.Binding definitions are part of the HTML/XML display page. There is onebinding definition per display page element that requires data. Thisorganization makes it easier to manage the binding definitions in thecommon display builder. It also makes it easy to access the bindingdefinition via the display page element at run time from script code inthe display page.

[0380] Each binding definition explicitly defines the mapping of datafrom the data reference object model on to the display page element. Thedefinition takes the form of a HENDRIX:BINDINGDEF element. The followingexample illustrates the broad features of a binding definition.   <!--the display page element -->   <SPAN ID=”Alpha1” CLASS=”Hendrix”BINDINGEF=”Alpha1BindingDef”><SPAN>   <!-- the binding definition -->  <HENDRIX:BINDINGDEF ID=”Alpha1BindingDef”>     <BINDINGTYPE=”Property” SOURCE=”OPC.DataRef1” TARGET=”PageElement.InnerHTML”/>  </HENDRIX:BINDINGDEF>   <!-- the data source definition -->  <HENDRIX:DATASOURCE NAMESPACE=”OPC”   CLSID=”DA943720-8048-11d2-8ED5-000000000000”>     <SERVER NAME=”Modbus”>       <GROUPUPDATERATE=”5000”>         <!-- the following corresponds to a referenceto ”OPC://Modbus.A100.PV” -->         <DATAREF NAME=”A100.PV”ID=”DataRef1”/>       </GROUP>     </SERVER>   </HENDRIX:DATASOURCE>

[0381] Each binding definition consists of one or more bindings thatdefine a property to property mapping between properties of datareferences and properties of the page element. In this example there isa single binding that maps data from OPC.Modbus.A100.PV to the InnerHTMLproperty of the page element with which this binding definition isassociated, in this case the SPAN element Alpha1.

[0382] Note that the type of the binding in this example is “Property”.This is the default type and is omitted, as required, from the BINDINGelement.

[0383] The source and target of a binding are a property of a sub-objectof a data reference or the page element, as in the following example.However, in other embodiments this is not the case.  <HENDRIX:BINDINGDEF ID=”Group1BindingDef”>     <BINDINGSOURCE=”OPC.DataRef1.PV” TARGET=”PageElement.Alpha1.Value”/>    <BINDING SOURCE=”OPC.DataRef1.SP”TARGET=”PageElement.Alpha2.Value”/>   </HENDRIX:BINDINGDEF>

[0384] At run time, each binding definition results in the creation of abinding object within the data binding engine.

[0385] A binding that binds an event to a method is of type “Event”. Ifthe signature of an event does not match that of the method to which itis bound a transformation is necessary to map the event on to themethod.

[0386] An important application of event binding is to bind a userinterface element that generates events to methods (commands) on datareferences.

[0387] The binding definitions described in above provide for a directmapping from the data reference object model to the display page. Inmany cases however, the data needs to be transformed, combined orfiltered in some way before being applied to the display page. There aremany examples where such transformations are required. One example isdata driven dynamics such as rotation, translation, path animation andbreak point animation that is to be applied to page elements. In thesecases the data to be delivered to the display page is derived from datareferences and the result is applied to the display page. Anotherexample is where a value to be delivered to the display page is theresult of some user written data driven script code as in the case ofGUS data reference expressions and OnDataChange scripts. A furtherexample is where an event is being mapped on to a method with anincompatible signature.

[0388] To accommodate these sorts of examples the binding engine's datatransfer mechanism is componentised to allow it to be extended withcomponents to provide arbitrarily complex transformations to beperformed as data and events are transferred from the data referenceobject model to the display page.

[0389] The three main types of transformation are property, event andOLE DB Rowset transformations. Property transformations transform data.Event transformations map an event on to a method facilitating argumentconversion and other processing. OLE DB Rowset transformations functionas OLE DB consumers and map a rowset into either a set of discreteproperties or another rowset. Mapping to a set of discrete properties isused to unpack a rowset and apply its contents to a variety of displaypage properties, while mapping to another rowset is used to performqueries, sorting, filtering or data reduction with the result beinganother OLE DB rowset (similar to the functions performed by OLE DBservice providers).

[0390] Transformations are objects with a series of “terminals” whichare used as inputs and outputs to the transformation. Thetransformations are “wired” into the binding definitions.

[0391] Transformations also include a programmatic interface that allowsit to be configured at display building time and manipulated at runtime. This interface includes methods, properties and events.

[0392] The following example illustrates how, in one embodiment, atransformation that derives an angle of rotation from a data referenceis included in a binding definition.   <!-- the display page element -->  <v:rect ID=”Rect1” CLASS=”   Hendrix” BINDINGDEF=”Rect1BindingDef”STYLE=”...”/>   <!-- the binding definition -->   <HENDRIX:BINDINGDEFID=”Rect1BindingDef”>     <XFORM ID=”RotationDyn” DEF=    ”CLSID:0EDB0680-81C8-11d2- 8ED6-000000000000”  PROPERTIES=”InitialAngle:0; RotationSpan:270; RangeLow:50;RangeHi:150”/>     <BINDING SOURCE=”OPC.DataRef1”TARGET=”RotationDyn.Value”/>     <BINDING SOURCE=”RotationDyn.Angle”TARGET=”PageElement.style.rotation”/>   </HENDRIX:BINDINGDEF>   <!-- thedata source definition -->   <HENDRIX:DATASOURCE NAMESPACE=”OPC”  CLSID=”DA943720- 8048-11d2-8ED5-000000000000”>     <SERVERNAME=”Modbus”>       <GROUP UPDATERATE=”5000”>         <!-- thefollowing corresponds to a reference to ”OPC://Modbus.A100.PV” -->        <DATAREF NAME=”A100.PV” ID=”DataRef1”/>       </GROUP>    </SERVER>   </HENDRIX:DATASOURCE>

[0393] In this example, the binding definition includes the XFORMelement which declares a transformation known as “RotationDyn” in thisbinding. The transformation is a binary component identified by theCLSID in the DEF attribute. The rotation transformation has a series ofproperties used to control the transformation from value to angle.Initial values for these are specified using the PROPERTIES attribute.

[0394] Once declared, the transformation is simply connected into thedata transfer mechanism using two separate bindings. The rotationtransformation has two terminals for this purpose, “Value” and “Angle”.The effect of this binding definition is that the value of thereferenced data item is converted to an angle of rotation and deliveredto the rotation property of the VML rectangle.

[0395] In this example the transformation was a binary component thatwas written in C++. However, in other embodiments use is made of thisand/or other programming languages such as Visual Basic, Java and thelike. This would be appropriate in this case since the rotationtransformation could be very widely used and overall performance of theHendrix architecture would benefit from a binary implementation.

[0396] Another option is to construct transformations using an XMLsyntax and script code. Following, there is a description of the use ofXML transformations, more detail on constructing binary transformations,and a more complex example that reproduces GUS functionality.

[0397] Transformations provide an extremely powerful and flexible way toextend the Hendrix data binding architecture. The previous example, acommon data transformation was packaged into a binary transformationcomponent so that it could be used to provide rotation dynamics fordisplay page elements. In the following example, the data transformationis one that is widely used across many different display page elements.This large scale reuse and the performance implications justify theinclusion of a binary transformation component.

[0398] There are many cases where a “one off” transformation is requiredfor a single instance of a display page element. This is the case when auser wants to tailor the delivery of data to the display page using somedata driven script code. A common example is when a page elementrequires a data value that is the result of some expression involvingseveral data references. XML based transformation components allow easeof construction of transformations that contain user written script thatis executed as part of the binding engine's data transfer mechanism.

[0399] The following is a simple example showing an XML transformationthat uses script code to calculate the sum of two data values.<HENDRIX:XFORMDEF ID=”Alpha1DataScriptDef”>   <TERMINAL ID=”Input1”NOTIFY=”Script1”/>   <TERMINAL ID=”Input2”/>   <TERMINAL ID=”Result”/>  <SCRIPT ID=”Script1” LANG=”VBScript”>         Result = Input1 + Input2  </SCRIPT> </HENDRIX:XFORMDEF>

[0400] The XFORMDEF element contains the definition of thetransformation. It has three terminals; Input1, Input2 and Result. Thereis a script element that contains VBScript code in this example. Thescript code uses the terminal IDs in the calculation of the sum. Theterminal Input1 has a NOTIFY attribute that names the script element.The effect is that any changes to Input1 will result in Script1executing. As will be appreciated by those skilled in the art, theterminal Input2 does not have the NOTIFY attribute which means thatchanges in Input2 will not result in any script executing. Thus, thewriter of the XML transformation has complete control over what causesthe transformation to transfer data.

[0401] The usage of this transformation in a binding definition would beas follows.   <HENDRIX:BINDINGDEF ID=”Alpha1BindingDef”>     <XFORMID=”ScriptComp” DEF=”Alpha1DataScriptDef”/>     <BINDINGSOURCE=”OPC.DataRef1” TARGET=”ScriptComp.Input1”/>     <BINDINGSOURCE=”OPC.DataRef2” TARGET=”ScriptComp.Input2”/>     <BINDINGSOURCE=”ScriptComp.Result” TARGET=”PageElement.Value”/>  </HENDRIX:BINDINGDEF>

[0402] In this case the DEF attribute of the XFORM element indicatesthat the transformation is an XML transformation defined in the currentdisplay page. The XML transformation, in other embodiments, is definedin a separate file in which case the DEF attribute might have the value“URL:Alpha1DataScriptDef.xml”.

[0403] It is also easy to construct bidirectional transformations usingXML transformations as the following illustrates. <HENDRIX:XFORMDEFID=”SignChangeDef”>   <TERMINAL ID=”Input” NOTIFY=”Script1”/>  <TERMINAL ID=”Output” NOTIFY=”Script2”/>   <SCRIPT ID=”Script1”LANG=”VBScript”>     Output = Input * −1   </SCRIPT>   <SCRIPTID=”Script2” LANG=”VBScript”>     Input = Output * −1   </SCRIPT></HENDRIX:XFORMDEF>

[0404] In this example two separate script elements, which performcomplementary transformations, execute in response to changes in theinput and the output.

[0405] XML transformations also include a programmatic interfaceconsisting of properties, methods and events. The following exampleillustrates an XML transformation that provides such properties and anevent. <HENDRIX:XFORMDEF ID=”BreakPtDef”>   <PROPERTY ID=”CurBreakPt”/>  <PROPERTY ID=”BreakPt1” NOTIFY=”Script1”/>   <PROPERTY ID=”BreakPt2”NOTIFY=”Script1”/>   <PROPERTY ID=”BreakPt3” NOTIFY=”Script1”/>  <PROPERTY ID=”BreakPt4” NOTIFY=”Script1”/>   <EVENT ID=”OnBreakPt”/>  <TERMINAL ID=”Input” NOTIFY=”Script1”/>   <SCRIPT ID=”Script1”LANG=”ECMAScript”>   if(DataVal < BreakPt1 && !(CurBreakPt == 1)   {    CurBreakPt = 1;         FireEvent(“OnBreakPt”);       }       elseif(DataVal < BreakPt2 && DataVal > BreakPt1 &&          !(CurBreakPt ==2)   {     CurBreakPt = 2;         FireEvent(“OnBreakPt”);       }      else if(DataVal < BreakPt3 && DataVal > BreakPt2 &&         !(CurBreakPt == 3)   {     CurBreakPt = 3;        FireEvent(“OnBreakPt”);       }   if(DataVal < BreakPt1 &&!(CurBreakPt == 4)   {     CurBreakPt = 4;        FireEvent(“OnBreakPt”);       }   </SCRIPT> </HENDRIX:XFORMDEF>

[0406] This transformation fires the OnBreakPt event whenever the inputvalue enters a new break point region. The break point regions asdefined by the four properties BreakPt1, BreakPt2, BreakPt3 and BreakPt4control the configuration of the transformation and the propertyCurBreakPoint reflects the current state of the transformation.

[0407] A transformation appears at run time as a subobject of the pageelement that it is associated with. This allows script code in thedisplay page to access the transformation's properties and methods andreceive any events it generates. This is illustrated in the followingexample which makes use of the above transformation.   <SPAN ID=”Alpha1”CLASS=”Hendrix” BINDINGDEF=”Alpha1BindingDef”/>   </SPAN>  <HENDRIX:BINDINGDEF ID=”Alpha1BindingDef”>     <XFORM ID=”BreakPt”DEF=”BreakPtDef”   PROPERTIES=”BreakPt1:40; BreakPt2:80; BreakPt3:120;  BreakPt4:160”/>     <BINDING SOURCE=”LCN.DataRef1”    TARGET=”BreakPt.Input”/>   </HENDRIX:BINDINGDEF>   <SCRIPTFOR=”Alpha1.BreakPt” EVENT=”OnBreakPt” LANGUAGE=”ECMAScript”>  switch(Alpha1.BreakPt.CurBreakPt)   {     case 1:SoundPlayer.Play(“normal.wav”);   break;     case 2:SoundPlayer.Play(“alert.wav”);   break;     case 3:SoundPlayer.Play(“highalert.wav”);   break;     case 4:SoundPlayer.Play(“codered.wav”);   break;     }   </SCRIPT>

[0408] Note that, in this example, there is no data actually transferredby the binding engine to the display page. Instead, the information isretrieved from the transformation by a display page script when thetransformation generates an event. Note also that the transformation isactually out-of-apartment with respect to the page element with which itis associated. This means that accessing the transformation incurs theusual performance penalty for such cross apartment calls.

[0409] It is also important to note in this example that the script codein the XML transformation is executed in the binding engine on a threadmanaged by the data source manager, while the script code responding tothe event fired by the transformation executes in the display page onthe main UI thread.

[0410] XML transformations are also used to map an event on to a methodwhen there is a mismatch between their signatures which means that thebinding engine cannot bind them directly. The following example showshow an XML transformation is used to map an event with one argument onto a method with two arguments. The transformation supplies the value ofthe second argument itself.   <HENDRIX:XFORMDEFID=”Alpha1EventXFormDef”>     <TERMINAL ID=”Input” NOTIFY=”Script1”/>    <TERMINAL ID=”Output”/>     <SCRIPT ID=”Script1” LANG=”VBScript”>    Method(Input.args(1), 10);     </SCRIPT>   </HENDRIX:XFORMDEF>  <HENDRIX:BINDINGDEF ID=”Alpha1BindingDef”>     <XFORM ID=”EventXForm”DEF=“Alpha1EventXFormDef”/>     <BINDING TYPE=”Event” SOURCE=    ”TPA.DataRef1.Recalculate” TARGET=”EventXForm.Input”/>     <BINDINGTYPE=”Event” SOURCE=”EventXForm.Output” TARGET=”PageElement.Rescale”/>  </HENDRIX:BINDINGDEF>

[0411] Note that the bindings in this case are of the type “Event”. Thedefault binding type is “Property”.

[0412] Note also the use of the args collection of the “Input” terminal.This collection is always available even on terminals used forproperties in which case args(1) contains the property value.

[0413] XML transformations are also used to alter the semantics of thedefault transformation that is implied by a binding definition thatbinds data directly from the data reference object model to the displaypage without the explicit use of transformations. This defaulttransformation has an equivalent XML definition as follows.<HENDRIX:XFORMDEF ID=”DirectBindingDef”>   <TERMINAL ID=”Input”NOTIFY=”Connection1”/>   <TERMINAL ID=”Output” NOTIFY=”Connection2”/>  <CONNECT ID=”Connection1” FROM=”Input” TO=”Output”/>   <CONNECTID=”Connection2” FROM=”Output” TO=”Input”/> </HENDRIX:XFORMDEF>

[0414] The CONNECT elements form a direct connection from one terminalto another. In this case, the default case, the connections are notifiedof any changes to their source terminals creating the effect of abidirectional connection. The semantics are changed by changing theNOTIFY attributes, adding extra connections etc. For example, atransformation that broadcasts a value to several page elements follows.  <HENDRIX:XFORMDEF ID=”DirectBindingDef”>     <TERMINAL ID=”Input”NOTIFY=”Connection1;     Connection2; Connection3”/>     <TERMINALID=”Output1”/>     <TERMINAL ID=”Output2”/>     <TERMINAL ID=”Output3”/>    <CONNECT ID=”Connection1” FROM=”Input” TO=     ”Output1”/>    <CONNECT ID=”Connection2” FROM=”Input” TO=     ”Output2”/>    <CONNECT ID=”Connection3” FROM=”Input” TO=     ”Output3”/>  </HENDRIX:XFORMDEF>

[0415] In this case changes in the input are propagated to the outputsbut changes in the outputs are not propagated back to the input. This isdifferent to the effect that would be obtained if the following bindingdefinition without explicit binding connections were used.  <HENDRIX:BINDINGDEF ID=”Group1BindingDef”>     <BINDINGSOURCE=”OPC.DataRef1” TARGET=”PageElement.Alpha1.Value”/>     <BINDINGSOURCE=”OPC.DataRef1” TARGET=”PageElement.Alpha2.Value”/>     <BINDINGSOURCE=”OPC.DataRef1” TARGET=”PageElement.Alpha3.Value”/>  <ENDRIX:BINDINGDEF>

[0416] The following example illustrates how transformations are used toreproduce GUS functionality. The scenario considered is that of a textobject with an OnDataChange script that references one data value and arotation dynamic driven by a data reference expression that is the sumof two other data values.

[0417] Firstly, an XML transformation is defined to capture theOnDataChange script and the data reference expression used to drive therotation dynamics. <HENDRIX:XFORMDEF ID=”Alpha1ScriptDef”   <TERMINALID=”Input1” NOTIFY=”OnDataChangeScript”/>   <TERMINAL ID=”Output1”/>  <TERMINAL ID=”Input2” NOTIFY=”DataReferenceExpr”/>   <TERMINALID=”Input3” NOTIFY=”DataReferenceExpr”/>   <TERMINAL ID=”Output2”/><SCRIPT ID=”OnDataChangeScript” LANG=”VB Script”>         Output1 =Func(Input1) </SCRIPT> <SCRIPT ID=”DataReferenceExpr” LANG=”VBScript”>        Output2 = Input2 + Input3 </SCRIPT> </HENDRIX:XFORMDEF>

[0418] Input1 is the input to the OnDataChange script and Output1 is theresult Input2 and Input3 are inputs to the data reference expression andOutput2 is the result of the data reference expression. This XMLtransformation and the binary rotation transformation discussed earlierare now used in a binding definition for a display page element.  <OBJECT ID=”Alpha1” CLASS=”Hendrix” CLSID=”...”BINDINGDEF=”Alpha1BindingDef”>   </OBJECT>   <HENDRIX:BINDINGDEFID=”Alpha1BindingDef”>     <XFORM ID=”Alpha1Script”DEF=”Alpha1ScriptDef”/>     <XFORM ID=”RotationDyn” DEF=    ”CLSID:0EDB0680-81C8-11d2- 8ED6-000000000000”  PROPERTIES=”InitialAngle:0; RotationSpan:270; RangeLow:50;RangeHi:150”/>     <BINDING FROM=”LCN.DataRef1” TO=    ”Alpha1Script.Input1”/>     <BINDING FROM=”Alpha1Script.Output1”TO=”PageElement.Value”/>     <BINDING FROM=”LCN.DataRef2” TO=    ”Alpha1Script.Input2”/>     <BINDING FROM=”LCN.DataRef3” TO=    ”Alpha1Script.Input3”/>     <BINDING FROM=”Alpha1Script.Output2”TO=”RotationDyn.Input”/>     <BINDING FROM=”RotationDyn.Angle”TO=”PageElement.Rotation”/>   </HENDRIX:BINDINGDEF>

[0419] As will be appreciated by a skilled addressee, given the teachingherein, a data source definition that defined DataRef1, DataRef2 andDataRef3 as referring to LCN://A100.PV, LCN://A200.PV and LCN://A300.PVrespectively is also required.

[0420] In this example, two transformations are chained together tobuild up the required combination of data transformations to achieve thedesired result.

[0421] From the preceding description, it is clear that explicittransformations are used when data needs to be transformed as it istransferred to the display page. The transformation is, in some cases,one that adds real value to the data as it is transferred—as in the caseof a rotation dynamic—or it is, in other cases—simply to massage thedata slightly into a form that the controls on the display page expect.This latter category of transformations is largely eliminated for thecontrols of the system provider or designer as a close correspondencebetween the form of the data as delivered by data source components andthe form expected by the controls on the display page is designed intothe system. This is also possible for controls targeting a specificserver system. To achieve this for controls that are reusable acrossprovider server systems requires convergence on the details of theobject models supplied by the various data source components.

[0422] The present embodiments also support another desired feature ofan industrial BIN, that being the ability to issue commands to theserver system. These commands are often issued from page elementsthemselves as in the case of selecting a page element and pressing afunction key to call up a point detail or right clicking a page elementto pop up a context menu from which an action can be selected. Commandsare, in some embodiments, also issued from the user interface frameworkas in the case of the-operator entering a command into the command zoneor selecting a menu item from the framework's menu.

[0423] Part of the power and flexibility of the architecture used in theembodiments of the invention comes from the separation of content frompresentation. This is achieved through the use of distinct data sourceand data transformations that free the page elements from most of thework involved in the provision of data to the display page. This has theadded and unexpected benefit that data is available to be provided toany page element, not just those supplied by the system designer orprovider. A similar approach is taken with commands that are issued tothe server system. These are abstracted out of page elements intodistinct components that allow the commands to be issued from any pageelement, not just those supplied by Honeywell or another systemprovider.

[0424] The command architecture of the preferred embodiments also allowscommand behaviour to be associated with any page element and forcommands from page elements and the user interface framework to berouted to the server system.

[0425] Commands are implemented as methods on objects in the data sourceobject model. Commands are, in some cases, system wide—such as commandsto change operator security level—or server specific—such asacknowledging alarms or calling up a point detail. These differentclasses of commands are implemented at the level of the data sourceobject model.

[0426] System wide commands are implemented on the root of the datasource object model. Server specific commands are implemented on theroot node of each data source component object model. The commands areusually accessed via script code or via command behaviours associatedwith display page elements.

[0427] The Hendrix architecture allows command behaviour to beassociated with any page element on a display page. This means, forexample, that a user is able to select a third party control on a pageand right click on it to pop up a server specific context menu or pressa function key to perform a server specific action such as point detail.

[0428] In the Hendrix architecture this ability to associate servercommand behaviour with any page element leverages the DHTML behaviourmechanism provided by MSHTML. A DHTML behaviour is a component thatencapsulates behaviour that would normally be coded into a page elementor added to it via script code. A behaviour component “wraps” any pageelements it is applied to, extending its object model and run timebehaviour. This mechanism provides the means by which server specificcommand behaviour is extracted out of page elements in a form that isable to be associated with any page element.

[0429] In practice, server command behaviours fall into several distinctcategories. In these cases, several individual behaviours areimplemented as part of the one behaviour component.

[0430] The command behaviour component implements the standard behaviourinterfaces such as IElementBehavior and IElementBehaviorFactory. Commandbehaviours respond to user events such as keystrokes and mouse clicks,and initiate the appropriate server commands when these events occur. Itissues the commands via the command methods in the data source objectmodel.

[0431] Associating a command behaviour with a page element is as simpleas applying the behaviour to the element via the standard CSSmechanisms. The following example shows how a command behaviour isassociated with a third party gauge control.   <!-- a third party gaugecontrol -->   <object id=“alpha1” CLASS=”PlansctapeCommands”classid=”clsid:36D15A51-1558-11d2-8dfA-00C04FF010A0” style=”position:absolute; top:500; left 500; height: 50; width: 100”>    <param name=“needleStyle” value=“4”>     <param name=“rangeLow”value=“0”>     <param name=“rangehigh” va1ue=“100”>   </object>

[0432] In other embodiments alternative associations are utilised.

[0433] In the case of a user interface framework, commands are usuallyissued directly to the data source object model, although this isdependent on the user interface element issuing the command and theimplementation strategy used in constructing the framework.

[0434] The ability to reuse display pages as building blocks for otherdisplay pages is an important factor in minimizing the engineering costof developing display pages for Honeywell and other provider serversystems. This holds is both for standard displays that are shipped witha system and for displays built for a customer site by consultants orthe customers themselves.

[0435] The Hendrix architecture provides three mechanisms for achievingdisplay page reuse. These are encapsulation, interface extension anddata reference parameterisation. Encapsulation refers to preparing aHendrix display page for later reuse by storing it in a separate file sothat it is available for being embedded or linked into a containingdisplay. Interface extension refers to adding properties, methods andevents to the display page so that it is available to be treated as afully fledged component in a containing display page. This greatlyincreases the utility of reusable display pages. Data referenceparameterisation refers to defining data references using tokens thatare substituted in the containing display when the display is linked orembedded.

[0436] Note that the previous description relies upon the file formataspects of display page reuse. Display page reuse is also an importantsource of requirements for the Honeywell common display builder.

[0437] A Hendrix encapsulation is formed when display page elements arecontained within a HENDRIX:ENCAPSULATION element and is stored in aseparate file. The following example the encapsulation of a span tagthat displays LCN.A100.PV and is stored in the file SimplePaceplate.htm  <HENDRIX:ENCAPSULATION>     <CONTENT>       <SPAN ID=”PVSpan”CLASS=”Hendrix” BINDINGDEF=”PVSpanBindingDef”/><SPAN>      <HENDRIX:BINDINGDEF ID=”PVSpanBindingDef”/>         <DATAID=”DataRef1”REF=”LCN.A100.PV”/>         <BINDING FROM=”DataRef1”TO=”PageElement.InnerHTML”/>       </HENDRIX:BINDINGDEF>     </CONTENT>  </HENDRIX:ENCAPSULATION>   The encapsulated display page elements arecontained   in the CONTENT element.   An embedded instance of theencapsulation follows:   <DIV ID=”Faceplate1”CLASS=”HendrixEncapsulation” DEF=”SimpleFaceplate.htm”>   <!-- contentof faceplate appears inline here -->   </DIV>

[0438] The embedded encapsulation appears as a DIV in the containingdisplay page with the HendrixEncapsulation behaviour applied to it.

[0439] Interface extension is achieved in the Hendrix architecture usingthe DHTML behaviour mechanism provided by MSHTML. This mechanism wasbriefly discussed earlier with reference to command behaviours. DHTMLbehaviours provide a general mechanism for extending the object model ofany display page element with properties, methods and events.

[0440] Properties, methods and events are added to an encapsulateddisplay by adding an INTERFACE element to the encapsulation. Thefollowing example provides an illustration.   <HENDRIX:ENCAPSULATION>    <INTERFACE>       <PROPERTY ID=”Prop1”/>       <METHODID=”Method1”/>       <EVENT ID=”Event1”/>       <SCRIPTLANGUAGE=”VBScript”>         sub Method1(x)        if#Encapsulation.Prop1 = 0 and x > 0 then              #Encapsulation.FireEvent(”Event1”);         end sub      </SCRIPT>     </INTERFACE>     <CONTENT>       <OBJECT ID=”PVSpan”CLASS=”Hendrix” BINDINGDEF=”PVSpanBindingDef”/><SPAN>      <HENDRIX:BINDINGDEF ID=”PVSpanBindingDef”/>         <DATAID=”DataRef1”REF=”LCN.A100.PV”/>         <BINDING FROM=”DataRef1”TO=”PageElement.InnerHTML”/>       </HENDRIX:BINDINGDEF>     </CONTENT>  </HENDRIX:ENCAPSULATION>

[0441] Note the use of the #Encapsulation symbol to refer to theproperties and methods of the current encapsulation.

[0442] An embedded instance of the encapsulation could look like:   <DIVID=”Faceplate1” CLASS=”HendrixEncapsulation” DEF=”SimpleFaceplate.htm”Prop1=”1”>   <!-- content of faceplate appears inline here -->   </DIV>  Note that Prop1 is given an initial value inline in the DIV element's  start tag.   The properties, methods and events are now available onthe embedded   instance for use in script code in the containing displaypage as follows.

[0443] Faceplate1.Prop1 = 2 Faceplate.Method1(3) <SCRIPTFOR=”Faceplate1” EVENT=”Event1” LANGUAGE=”VBScript”>   ‘event handlercode here </SCRIPT>

[0444] An encapsulation, as used in some embodiments, includes datareference tokens that are used to parameterise data references thatappear in the encapsulated display page. The following illustrationshows one method of parameterising the data reference in the previousexamples.   <HENDRIX:ENCAPSULATION>     <INERFACE>       <TOKENID=”PointID/>     </INTERFACE>   <CONTENT>       <SPAN ID=”PVSpan”CLASS=”Hendrix” BINDINGDEF=”PVSpanBindingDef”/><SPAN>      <HENDRIX:BINDINGDEF ID=”PVSpanBindingDef”/>         <DATAID=”DataRef1” REF=”##PointID.PV”/>         <BINDING FROM=”DataRef1”TO=”PageElement.InnerHTML”/>       </HENDRIX:BINDINGDEF>     </CONTENT>  </HENDRIX:ENCAPSULATION>

[0445] The data reference now includes the symbol ##PointID, which is aninstance of the token PointID. PointID is declared as a data referencetoken using a TOKEN element in the INTERFACE part of the encapsulationWhen the encapsulated display page is embedded or linked into anotherdisplay page the data reference tokens are given values which are thensubstituted into the tokenised data references within the encapsulateddisplay page.

[0446] The following example illustrates how the encapsulation is usedin a containing display page.   <DIV ID=”Faceplate1”CLASS=”HendrixEncapsulation” DEF=”SimpleFaceplate.htm”      PointID=”LCN.A100”>   <!-- rest of faceplate appears inline here-->   </DIV>

[0447] In this case the token PointID is given the value LCN.A100.

[0448] When determining what data references exist in the embedded (orlinked) encapsulation, the Honeywell common builder performs a tokenpasting operation to complete any parameterised data references.

[0449] The data reference tokens are accessible at run time as part ofthe embedded (or linked) encapsulation's object model. For example, thefollowing line of would cause the bindings that depend on the token tobe unbound and then rebound to new objects in the data source objectmodel.

[0450] Faceplate1.Tokens(“PointID”)=“LCN.A200”

[0451] This assumes that the data source object model already containsthe data for LCN.A200. The containing display page will look after thisdetail using the technique suggested earlier with reference to databinding definitions.

[0452] If token values are omitted from an embedded encapsulation at thetime it is embedded, the data references and binding definitions thatdepend on them are ignored. Token values are then supplied at run timecausing the binding definitions to take effect at that time.

[0453] As discussed so far in this description, the Hendrix architecturetypically consists of a client machine on which display pages are viewedand one or more server systems from which data is delivered to theclient. The data is delivered to the client machine by the server systemspecific data source components and presented to the data source managerin the form of hierarchical object models. The data source managerconsolidates the various data source component object models into asingle data source object model. The binding engine, which is alsomanaged by the data source manager, then transfers the data from theobject model to the display page as changes occur. This arrangement isshown in FIG. 21.

[0454] The client portion described above is also, in the preferredembodiments, run on a server system. This is usually necessary in caseswhere a data source component does not include a remoting mechanism fordelivering data to a separate client machine. FIG. 22 illustrates thisarrangement.

[0455] These two topologies both feature a thin client and are suitablein some control room scenarios where conventional workstations are thenorm and network connections are regarded as potential points offailure.

[0456] There are, however, other topologies for the Hendrix architecturethat are used in other embodiments. As discussed in previously, the databinding engine executes in an apartment managed by the data sourcemanager. The motivation for this is to offload the work associated withdelivering data and transforming to a thread other than the main userinterface thread. Communication between the binding engine and thedisplay page is an efficient batch transfer mechanism that minimizesinter-apartment round trips. This split between the servers systems andthe data source manager (different machines) and the data source managerand the display page (different apartments) makes Hendrix a three-tierarchitecture. The data source manager and the components it manages formthe middle tier. If the interface between the data source manager anddisplay page is made remotable, as is the case in some embodiments, thena number of other network topologies are possible.

[0457] These topologies feature a very thin client and would be suitablefor very thin client platforms such as hand held and wearable computers.One locates the middle tier on one of the server systems while the otherlocates it on a distinct machine. These are illustrated in FIG. 23 andFIG. 24.

[0458] The thin client topologies allow the data source manager to beshared across display pages on the same machine while the very thinclient topologies allow the data source manager to be shared acrossdisplays on different machines. This allow the data source manager toact as a common “display database”.

[0459] Another advantage of the very thin client approach is that onlythe data actually needed on the page is sent to the client rather thanall of the data required to derive the needed data, thus minimizing thevolume the data communications to the client. This is important forclients operating over low bandwidth communications links.

[0460] Having the middle tier on a distinct machine is also importantwhere computationally expensive transformations are performed intransformations as occurs where historical data from server systems isbeing prepared for a complex 3D data visualization. This functionalityenables very thin clients to present the visualization and also avoidloading the server systems with the computational burden.

[0461] In some embodiments the middle tier represents the ideal placefor a web server used to deliver display pages to the clients. Oneimplication of this is that it is better for the data source definitionsand binding definitions to be stored separately from the display pageand passed directly to the data source manager as the display page isdelivered rather than having them passed to the client as part of thedisplay page only for them to be sent back to the middle tier.

[0462] There are different classes of user of an industrial HMI rangingfrom those who require casual access to display pages via a web browserto those who spend all day working with display pages at a dedicatedconsole in a control room. These different users have differentrequirements for the environment in which they use display pages. Thesediffering requirements are reflected in differing display pageframeworks. A display page framework is generally some surrounding userinterface infrastructure that helps the user to navigate and interactwith display pages. This infrastructure includes menus, toolbars, statuszones, alarm zones, message zones, command zones, change zones, and thelike. Another important class of framework functionality is the windowmanagement provided by software such as the commercially availableHoneywell SafeView product.

[0463] The Hendrix architecture, in conjunction with SafeView, providesa rich tool kit for constructing display page frameworks. Sometechniques for constructing frameworks using the Hendrix architectureare described below.

[0464] The simplest form of framework is no visible framework at all.This occurs when, for example, SafeView alone is used to manage the userinterface of an operator console. This is achieved by using theHypertext Application (HTA) mechanism available in MSHTML. This allows adisplay page to appear standalone without any visible framework, much inthe same way that present day GUS displays appear.

[0465] The common model for casual access to information is the webbrowser. Internet Explorer provides a state of the art web browsinginterface that is ideal for casual access to display pages. Displaypages are called up by entering a direct URL in the browser or by any ofthe other myriad navigation tools available in this environment.Examples include favourites or bookmarks, navigation history andhyperlinks from other display pages or from other HTML pages that arepart of the general corporate intranet.

[0466] In the case of a web browser, the framework in which pages areviewed is the regular web browser user interface. It does not includeany user interface elements that are HMI specific. In general this isnot a limitation. In some cases however, there is a need for some extrauser interface elements in the display page itself to allow the user tointeract with the process or server system in a way that would normallybe provided by an HMI specific framework. An example of this is aminimal user interface to allow the user to enter commands into acommand zone. This minimal user interface is, in some cases, deliveredas a control on the display page whose visibility would be determined bythe framework in which the display page is viewed.

[0467] Industrial process control systems, such as those provided byHoneywell, are used in many industrial domains. The operationalenvironments that exist in these domains vary greatly depending on thenature of the processes being managed. Even within a particular domain,operational requirements will vary with different operational policiesin place at different organizations.

[0468] As discussed above, a framework is some user interfaceinfrastructure in which display pages can be viewed, navigated andinteracted with. A framework typically contains user interface elementssuch as menus, toolbars, status zones etc. The Hendrix display pagearchitecture itself provides a perfect mechanism for constructing theseframeworks. This is especially true as the Hendrix data bindingarchitecture makes it easy to populate the framework with data from theserver system and process.

[0469] Third party tools are rapidly emerging with which rich HTML baseduser interfaces can be constructed. Examples of these include menus andtoolbars implemented as binary behaviours for use with MSHTML.

[0470] Display page scripting is provided by MSHTML. It supports scriptcode written in any language for which an ActiveX scripting engineimplementation is available. The most popular scripting languages on webpages are JavaScript, now known as ECMAScript and VBScript. Microsoftprovides ActiveX scripting engine implementations for both languages.

[0471] The one aspect of display page scripting that is provided by theHendrix architecture is named data access.

[0472] An important aspect of providing data to a display page is thatof making the data available to script code in the display page. In theHendrix architecture this means making the data source object modelaccessible to the display page scripting environment. This is done viathe data source connector which provides an object model that mirrorsthe data source object model. This object model actually provides alocal, standard OLE Automation version of the data source object model.As an optimisation, the data source connector object model is created onan as needed basis, as it is accessed, by executing script code.

[0473] Script code on the page accesses data in the data source objectmodel simply by referring to it via the data source connector which, forconvenience, is called “Data” in the display page.

[0474] DataOPC.A100.SP=100

[0475] This example assumes that the data item OPC.A100.SP actuallyexists in the data source object model. The earlier description on thedata binding architecture describes how to make sure the data sourceobject model contains all of the data that display page script codemight require.

[0476] Robustness and stability are essential features of an IndustrialHMI. The Hendrix architecture is designed in such a way as to minimizethe impact of failures in HMI components. The main areas of risk areActiveX controls in the display page, user written script code in thedisplay page, binary transformations and XML transformations. These areall areas where it is possible for “foreign” components to be introducedinto the HMI. These foreign components provide a risk of catastrophicfailure or, in less acute cases, simply take too long to execute.

[0477] The failure of any one of these components will have a directimpact on the particular display page which those components are a partof or are servicing. The Hendrix architecture is designed such that theimpact of any of these failures will be limited to that particulardisplay page. This extends to any user interface framework that ismanaging a display page. This ensures that even if a display page failscatastrophically, the framework will remain intact so the user is ableto continue to receive process and system information through theframework and/or navigate immediately to another display page.

[0478] In some embodiments, special components are developed to achievethe desired robustness. For example, specific robust display pagecontainers that execute a display page in a separate process on behalfof a user interface framework.

[0479] The script code execution environments (MSHTML and the XMLtransformations) monitor the execution of script code so that code thattakes too long to execute is identified and remedial action taken.

[0480] Inter-display communication consists of two aspects:

[0481] 1. Communication at display invocation time, consisting of theability of one display being able to pass parameters to another when itis invoked, and

[0482] 2. Communication after a display is loaded, consisting of theability to share persistent data between displays, and across displayinvocations.

[0483] A display may be invoked in one of two ways: either in the samewindow as the calling display (such as a normal hyperlink in thebrowser) or in a new window. When it comes to passing invocationparameters to such a display, these two scenarios are slightlydifferent.

[0484] When changing to a new display in the same window, displayparameters are used to transmit some kind of state information (such asthe currently selected point, or previously entered user data) to thenew display. In the Hendrix environment, there are a number of methodsavailable for this purpose, the first three of which utilise webtechnologies:

[0485] 1. Storing the information in a cookie as part of the documentobject model.

[0486] 2. Storing the information as structured XML data (available inIE5).

[0487] 3. Storing the information on the server, by using Active ServerPages and placing the parameters in the hyperlink definition (e.g.http://server/new_display.htm.?param1=20&param2=30).

[0488] 4. Using the global data repository provided by the global datarepository (see below).

[0489] As far as Hendrix is concerned, any of these methods areappropriate to pass parameters to a new display. The Hendrixarchitecture is designed to permit the use of pertinent technologies,but not mandate it. The architecture does not require the use of ActiveServer Page technology, for example, but likewise it does not prohibitits use where appropriate. Note that adopting a custom form of hyperlink(where parameters are passed locally on the client, for example) wouldnot be appropriate, as the parameter passing mechanism needs to functionin both the web browser and the operator environments.

[0490] This is not the case when displays are invoked in a separatewindow, however. In HTML, a new window is opened by a normal hyperlink,or by script, as for a single window. The difference lies in the factthat the system must determine what frame window to use for the newwindow. Consider the following scenarios: Invoked Invoking DisplayDisplay Expected Behavior Display in operator New Invoked display shouldbe called up in environment display the operator environment. If customframe windows are used for the operator environment, the new displayshould be called up within such a frame window. Display in browser NewInvoked display should be called up in a display browser window. Displayin operator Popup Popup window should be called up in environmentfaceplate custom faceplate frame window. Display in browser Popup Popupwindow should be called up in faceplate either custom faceplate framewindow, or browser window without toolbar/menu. A fall browser window isnot appropriate for popup faceplates.

[0491] These scenarios illustrate that the behaviour of invoked windowsis not fixed, and instead depends on the environment in which they areviewed and the type of display being invoked. Other scenarios are alsopossible. (Note that popup faceplates have their own specializedrequirements, and are described further elsewhere in this description).

[0492] While the normal hyperliking mechanism allows the new document beopened in a second window, it does not provide any mechanism for passingarbitrary parameters to this new document. Even more importantly, it isunable to dynamically determine if the new window should be created in abrowser window or in a frame suited to the operator environment. Tocreate external windows, and to pass parameters to them, script must beused.

[0493] There are a number of possible methods for passing parameters toa new display at invocation time. These include the use of client-sidemechanisms such as cookies, structured XML data stores, the global datarepository (described below), and even the use of HTML behaviours toallow a display to expose properties, methods and events. None of thesemethods, however, ensure that the parameters being passed areinitialised before the new display begins executing. This result indisplays showing invalid data upon invocation, and also, in more extremecases, result in script errors. While any of these mechanisms are usablein the Hendrix architecture, the standard way to invoke displays andpass parameters to them is provided by the data source connector.

[0494] The data source connector provides a method call for the creationof new displays, as follows:

[0495] window2=DatacreateWindow(URL [, parameter_string])

[0496] Where parameter_string is a single string that is capable ofspecifying an arbitrary number of named parameters. Its format ismodelled on the format used for specifying CSS attributes in HTML, andis a semi-colon delimited list of name/value pairs. Each name/value pairis of the form name: value. For example:

[0497] createWindow(“display2.htm”, “param1:LCN.A100.PV;servername:chevron5”);

[0498] createWindow(“display3.htm”, “param2:‘embedded string asparameter’”);

[0499] The data source connector invokes the new display and passesparameters to it according to the following sequence:

[0500] 1. The data source connector invokes a new display with the givenURL via the method appropriate to the current environment (browser oroperator). The data source connector is aware of whether it has beenloaded in the browser or an operator frame, and is thus able to decidehow it should create the new window.

[0501] 2. The data source connector on the new display obtains a pointerto the invoking data source connector (via the opener property of thewindow object in the DOM.)

[0502] 3. The data source connector on the new display retrieves theparameter list. It does this by utilizing the IHendrixDisplayParametersinterface exposed by the invoking data source connector. TheIHendrixDisplayParameters interface is detailed below.

[0503] 4. If no parameters are to be passed (the parameter list isempty), or no invoking display exists (the opener property is null), thenew data source connector fires the OnPageLoadComplete event into theDOM. Display pages must be written such that no data processing cancommence prior to this event being fired.

[0504] 5. If display parameters are to be passed, the new data sourceconnector retrieves the parameter string, exposes the passed parametersvia its own object model as explained below, and fires theOnPageLoadComplete event. The page is then ready to commence normalprocessing.

[0505] The data source connector exposes parameters it has retrieved aspart of its own object model, in the displayParameters collection. Acollection is used, rather than extending the object model ofhigher-level objects in the DOM, to avoid the possibility of namespacecollisions. Parameters are accessed by name or by index (according tothe order they were placed in the original parameter string). So, forthe first example above:

[0506] val1=Data.displayParameters(0) ‘val1=“LCN.A100.PV”

[0507] val2=Data.displayParameters(“servername”) ‘val2=“chevron5”

[0508] The Hendrix global data repository is, as its name implies, aglobal repository of data which facilitates inter-display communication.It is a component of the data source manager, and functions as a datasource component, supplying the binding engine with an object model thatis able to be bound to elements on a display page. The data repositoryis thus ‘global’ in the sense that all displays served by the datasource manager are able to access its data. For a single-node system(refer to FIG. 22) this implies that the data is machine-wide. In thecase of a distinct middle tier, however (refer to FIG. 23), this impliesthe ability to share display data across nodes. The global datarepository replicates the functionality of the Display Database found inGUS systems.

[0509] The Hendrix global data repository has a number of requirements,in that it:

[0510] 1. Allows the user, through script, to store values in a globalrepository, from where those values are retrievable by other displaysrunning on the machine. This global data must remain available evenafter the display is terminated.

[0511] 2. Allows the user to store values in a local repository. Data inthe local database has a lifetime dictated by the lifetime of thedisplay itself—when the display is unloaded or changed, the local datais lost. The original reasons for a local repository were for migrationfrom LCN to GUS. In many ways a local database is no different fromuser-defined variables in script on a page, and for those embodimentswhere migration issues are solved, then it would not be required.

[0512] 3. Allows the user to bind to data values stored in the datarepository. This means that one display (or even an externalapplication) is able to drive the data shown on a second display simplyby changing values in the data repository.

[0513] 4. Allows the user to store references to data as variables inthe database. These variables are updated live to reflect real processvalues in a target system.

[0514] 5. Allows objects on a page to bind to data references in theglobal data repository. In GUS terminology, this means the ability toreference objects in the global data repository in the body of anOnDataChange script. In the Hendrix architecture, this translates to theability of the binding engine to map data from the global datarepository on to the page.

[0515] The above describes how the first three of these requirements(related to storing simple variables) are implemented in the Hendrixarchitecture. The ability to store references in the repository isdiscussed elsewhere.

[0516] Access to the global data repository is provided by the datasource connector on each page. This object provides script on the pageaccess to the data repository functionality via the DOM. The global datarepository is based around a name-based collection of user-definablevariables, rather than a fixed set of attributes. The user is able todefine their own database variable names, allowing for greaterflexibility.

[0517] The data source connector has three methods related to thestorage of simple variables (Add, Item, Remove) and one property(count). These function as follows:

[0518] Data.Add:

[0519] Adds a new item, in the form of a named variable, to the globaldata repository. The syntax for this operation is:

[0520] Data.Add(name, value)

[0521] where name is a string, and value is a variant. For example:

[0522] Data.Add(“val01”, 97.2)

[0523] Data.Add(“val02”, “string_value”)

[0524] Data.Item

[0525] Returns the specified item from the global data repository. Thesyntax for this operation is:

[0526] Data.Item(name)

[0527] For example:

[0528] savedValue=Data.Item(“val01”)

[0529] Data.Remove

[0530] Removes an item from the global data repository. The syntax forthe operation is:

[0531] Data.Remove(name)

[0532] Data.count

[0533] Returns the number of user-defined variables in the global datarepository collection.

[0534] In addition to providing a global repository of data, in whichstored variables and data references remain persistent across pagechanges, the data source connector also provides local storage todisplay pages. Data stored in the local database only exists during thelife of the display, and is accessible by any object in the display. Thenames of items in the local database are only visible to the displayusing them.

[0535] A display's local database possesses the same functionality asthe global database. It is accessed using the DataLocal sub-object,using the same functions as the global database. For example:

[0536] Data.Local.Add(“val01”, 97.2)

[0537] Data.Local.Item(“val01”)

[0538] Data.Local.Remove(“entity1”)

[0539] Data.Local.count

[0540] The Hendrix architecture also provides the ability to bind todata items in the data repository. This is accomplished via the normaldata binding mechanisms, with the implication that the global datarepository functions as a data source component, managed by the datasource manager. This aspect of the architecture is illustrated in FIG.25.

[0541] The binding definition for an object bound to data in the datarepository is relatively straightforward. For example:   <BODY>    <SPAN ID=”Alpha1” CLASS=”Hendrix; PlantscapeCommands”BINDINGDEF=”Alpha1BindingDef”>     </SPAN>     <HENDRIX:BINDINGDEFID=”Alpha1BindingDef”>       <DATA ID=”DataRef1”REF=”Data.Item(‘val01’)”/>       <BINDING SOURCE=”DataRef1”TARGET=”PageElement.InnerHTML”/>     </HENDRIX:BINDINGDEF>   </BODY>

[0542] The global data repository also allows the user to storereferences to process data, which, when retrieved by a display page,reflect real process variables in a target system. For example, thereare circumstances where a user requires to store the value ofLCN.A100.PV in the display database variable “var01”, and have thisvariable updated automatically to reflect the value of the processvariable. This process is substantially different from the ability tostore simple values.

[0543] As described above, the data repository behaves like a datasource component when it comes to simple values. For data references,however, this is not the case. Data references must continuouslyretrieve data from the server system, thus placing a load on bandwidth.As items in the data repository are globally persistent, this means thatvaluable bandwidth could be taken even when no displays are loaded on amachine. This is clearly undesirable. Ideally, data should only be beinggathered by data source components when that data is required in someform by a currently loaded display.

[0544] To realise this optimisation, the data repository does not behaveas a data source component for data references, but as a data sourcedictionary. It provides a dictionary service to the data source manager,which in turn allows data source components to achieve a form of dataindirection when the page is loaded. This facility is explainedelsewhere in the specification. To a user, however, the ability toaccess data references appears no different from the ability to accesssimple values in the repository, as explained below.

[0545] Data references are stored in a similar way to simple variables,through a set of three methods (AddRef, ItemRef, RemoveRef) and oneproperty (countRef). These function as follows:

[0546] Data.AddRef

[0547] Adds a new item, in the form of a named variable, to the displaydatabase. The syntax for this operation is:

[0548] Data.AddRef(name, value [, xml_data])

[0549] where name is a string, and value is a string name representingeither a parameter or an entire object in the data source object model.If an entire object, it is assumed any properties or sub-objects areimplicitly included in the display database. For example:Data.AddRef(“val01”, “LCN.A100.PV”) ‘parameter referenceData.AddRef(“val02”, “LCN.A100”) ‘entity (or object) reference

[0550] The optional parameter, xml_data, is an XML structure definingserver-specific information pertaining to data collection (e.g. updaterates, collection groups, etc).

[0551] Data.ItemRef

[0552] Returns the specified item from the display database. The syntaxfor this operation is:

[0553] Data.Item(name)

[0554] For example:

[0555] savedValue=Data.ItemRef(“val01”)

[0556] savedValue2 =Data.ItemRef(“val02”).PV

[0557] Some data source components may have pre-defined server-specificentities intended to represent certain aspects of the server system. Asdata references are stored as strings, any syntax may be used toreference these items. For example:

[0558] Data.ItemRef(“val03”, “LCN.$AL_ENTY”) ‘server-specific entity,

[0559] Data.RemoveRef

[0560] Removes an item from the display database. The syntax for theoperation is

[0561] Data.RemoveRef(name)

[0562] Data.countRef

[0563] Returns the number of user-defined data references in the displaydatabase collection.

[0564] Display page objects are also, in some cases, bound to referencesin the data repository, the same as simple variables. For example, thefollowing binding definition is used to bind an object to the datareference stored in the item “val01”:   <BODY>     <SPAN ID=”Alpha1”CLASS=”Hendrix; PlantscapeCommands” BINDINGDEF=”Alpha1BindingDef”>    </SPAN>     <HENDRIX:BINDINGDEF ID=”Alpha1BindingDef”>       <DATAID=”DataRef1” REF=”Data.ItemRef(‘val01’)”/>       <BINDINGSOURCE=”DataRef1” TARGET=”PageElement.InnerHTML”/>    </HENDRIX:BINDINGDEF>   </BODY>

[0565] As mentioned previously, the data repository does not actuallystore references to data, in an attempt to reduce possible bandwidthusage. Instead, it supplies a dictionary of reference information thatthe data source manager uses to look up when a page is loaded. A typicalsequence is as follows:

[0566] 1. Initial display stores a reference to “LCN.A100.PV” in thedata repository reference “val01”.

[0567] 2. Subsequent display is loaded, with a reference to“Data.ItemRef(‘val01’) in its data definition, along with the usualfixed data references (e.g. LCN.A101.PV). It passes this data definitionto the data source manager.

[0568] 3. The data source manager detects that an indirect datareference through the data repository is required. It queries the datarepository to resolve this to a reference to actual data.

[0569] 4. The data source manager then hands the fully-resolved datasource definition to the appropriate data source, which then constructsits part of the data source object model.

[0570] 5. The binding engine binds directly from the data sourcecomponent to the page. No binding is performed from the data repositoryto the page.

[0571]FIG. 26 schematically illustrates the sequence of events upon pagecallup.

[0572] In this scenario, dynamic data is only retrieved by a data sourcecomponent when it is required by a page. When the page is unloaded, thedata source component unloads any referenced data from its object model.The only persistent data is the dictionary lookup information in thedata repository that maps “val01” to “LCN.A100.PV”.

[0573] This process results in efficient use of communications bandwidthbetween data source components and their respective servers. It does,however, bring into question the issue of performance. For systems wherethe mapping between human-readable data reference name and actualmachine identifier is slow, a performance penalty will be paid everytime a page is loaded. This performance penalty is avoided by allowingthe data repository to store pre-binding information along with thedictionary item.

[0574] This concept is similar to the ability to perform a pre-bindingstep in the builder. For data defined at build time, the data sourcecomponent supplies a service to the builder which translates the humanreadable data tags into machine identifiers. This server-specificinformation is then stored with the data definition, and passed to thedata source component at runtime to enable fast callup of the page. Inthe case of the data repository, the situation is similar. When the datareference is first defined (via a call to Data.AddRef), the data sourcemanager queries the data source component for any pre-bindinginformation it may supply. This pre-binding information is then storedin the repository along with the dictionary item. On page callup, whenthe data reference is actually required, the pre-binding information ispassed to the data source component in order to ensure fast retrieval ofthe data.

[0575] At runtime, it is possible for a display to change the referencestored in the data repository. In the above example, with a page elementbound to “LCN.A100.PV” via indirection through “val01” in therepository, the following script code is executed on the display:

[0576] Data.AddRef(“val01”, “LCN.A200.PV”)

[0577] This script not only alters the dictionary reference stored inthe repository, but also re-bind any page elements currently bound toLCN.A100.PV to LCN.A200.PV. This implies the following capabilities ofthe architecture:

[0578] 1. The data source component must be able to incrementally addLCN.A200.PV to its object model.

[0579] 2. The data repository must be aware that page objects arecurrently bound to objects in the data source object model via anindirection through “val01”, and inform the data source manager when itsvalue changes.

[0580] 3. The binding engine must be able to dynamically re-bind to thenew data element.

[0581] Dynamic binding (in which bindings between data objects and pageelements are modified at runtime) differs from static binding (in whichbindings are defined at build time and created when the page isinitially invoked). To achieve dynamic binding, the binding engineexposes the IHendrixDynamicBinding interface. The data source manageruses this interface at runtime to tell the binding engine to set up abinding between data and a new object in the display database.

[0582] Popup window functionality differs slightly from more genericinter-display communication, in that the invoked popup window generallyencapsulates specialized functionality, and is expected to behavedifferently on screen from a normal display window. Examples of thisinclude faceplates, where extra functionality is required to determinewhich faceplate to invoke, as well as complex lifetime management forpush-pin type popup windows.

[0583] The invocation of popup windows involves several distinct areasof functionality, each of which imposes requirements on the Hendrixarchitecture:

[0584] Identification

[0585] A standard method is required for identifying which popup windowneeds to be invoked. In the case of faceplates, this will depend on thecurrently selected object, or tag name in the system.

[0586] Invocation

[0587] The architecture must accommodate a standard method for theinvocation of popup windows.

[0588] Position Management

[0589] In some systems, operators are accustomed to activating a largenumber of modeless popup windows. When multiple displays are shown on asingle machine, some way must be provided to manage these popup windows.

[0590] Lifetime Management

[0591] Popup windows must have the ability to be “push-pinned”, so thatthey are not terminated when the originating display changes. Thearchitecture must provide lifetime management services to facilitatethis functionality.

[0592] Preferences

[0593] The TPA system requires the ability to “store” an arrangement offaceplates for a display, so that when the operator returns to thatdisplay the arrangement of faceplates reappears in the configuredpositions on screen, without having to be invoked individually by theoperator.

[0594] The above limitations are now discussed in more detail withreference to the way in which the preferred embodiments of the inventionaccommodate these limitations.

[0595] The ability to identify which faceplate to invoke for a givenpoint or tag, or object on a display, must be accessible from script,and also activated inherently as part of the architecture (for example,when a screen object is double-clicked).

[0596] First consider the scripting case. When the point name is known,the associated faceplate name is retrieved by a simple call on the datasource connector:

[0597] faceplateName=Data.getFaceplate(point_name)

[0598] where both point_name and faceplateName are strings. The pointidentifier must be fully qualified, in that it identifies the datasource on which the point resides (“LCN.A100”, for example). Thefaceplate name is a URL.

[0599] At times, however, the point name will not be known, and the userwill want to determine the faceplate associated with an HTML elementdirectly. This functionality is provided by the same method on the datasource connector, only taking a reference to an element in the DOMinstead of a string:

[0600] faceplateName=Data.getFaceplate(element)

[0601] The element is specified directly via the element ID, or byspecifying its position in the DOM (document.group1.text1, for example).

[0602] The above methods provide the ability to identify a faceplatename via script. In general, however, it is preferable that faceplateinvocation is not handled through script on a page (as it would thenneed to be written for every object on that page), but instead as aninherent part of the architecture. This capability is provided by abinary HTML behaviour, which is then applied to all objects on a page.The behaviour is then responsible for the method of invocation(right-click, double-click, etc.), for identifying which faceplate toinvoke, and the invocation itself.

[0603] In the case of a binary behaviour, the method used to retrievethe faceplate name is still the same: method calls on the data sourceconnector. It is envisaged that the faceplates are invoked as part of aconverged user interface, although as to how these behaviours arestandardized across all Hendrix implementations is not relevant. This isa matter for the style guide and has no impact on the architecture.

[0604] Note also that this method of faceplate identification placesspecific requirements on the architecture components, as follows:

[0605] 1. The data source connector must expose the getFaceplate methodcall.

[0606] 2. The data source manager, and specific data source componentsbeneath it, must be able to map a point name to a faceplate name, toenable the first type of call to getFaceplate to work.

[0607] 3. The binding engine must be able to provide a backward mappingfrom an object in the DOM to the data object which is driving it. Thedata source component, subsequently, must be able to map this dataobject into a point name, to honour the second type of call togetFaceplate.

[0608] There are two types of popup window generally required to becalled from script—faceplates representing point details, and data entrydialog boxes intended to return information to the calling window. Theseare each invoked in different ways.

[0609] A dialog box is either modal or modeless. A modeless dialog box,constructed from HTML, is no different from activating a separatedisplay window. In the pure HTML world, this would be accomplished by acall to window open, with parameters used to specify that no toolbar,menus, etc are required in the invoked window. In the Hendrixarchitecture, this is accomplished with a call to Data.createWindow. Thedata source connector needs to be aware of its environment, to decidewhether to create the window in a browser window or an appropriateframework window. The need to be able to create a modeless dialogwindow, however, adds extra requirements to the createWindow method,namely that it accepts the same parameters as the window.open method,allowing the creation of modeless dialog boxes in the web browserenvironment. Thus the full syntax of the createWindow method is:

[0610] window2=Data.createWindow(URL [, parameter_string

[0611] [,name

[0612] [,features

[0613] [,replace]]]]);

[0614] where URL and parameter_string are explained above, and name,features, and replace are the same as the parameters used in thewindow.open method. Information is passed between the dialog box and thecalling window as described above.

[0615] To create a modal dialog box in a normal HTML page, thewindow.showModalDialog method is called. Similar to the case for openingseparate windows, however, the appearance of the invoked modal dialogdepends on the environment in which it is invoked. In the browserenvironment, it is acceptable to display the standard Internet Explorerdialog, but in the operator environment a more custom frame may berequired. Thus the data source connector exposes the following method:

[0616] variant=Data.showModalDialog(URL [, vArguments [, sFeatures]])

[0617] Here the parameters are the same as those used in thewindow.showModalDialog method—the only difference is that the frame usedfor the invoked dialog box is dependent upon the environment.

[0618] Faceplate windows are different, in that a faceplate has noparallel in the HTML world. The frame window used for faceplatesincludes, for example, a pushpin button to allow faceplates to be kepton the desktop even as the underlying page changes. The frame windowused for faceplates will be the same in both web browser and operatorenvironments. Faceplates themselves will be created in HTML.

[0619] The invocation of a faceplate is executed as a method call on thedata source connector. This call often takes multiple forms:

[0620] window2=Data.showFaceplate(sURL [, parameter string [,sFeatures]])

[0621] window2=Data.showFaceplate(point_name [, parameter_string [,sFeatures]])

[0622] window2=Data.showFaceplate(object [, parameter_string [,sFeatures]])

[0623] The first of these calls simply specifies the faceplate filename(which may have been previously retrieved by a call to getFaceplate),and an optional display parameter string, using the same method outlinedfor passing parameters as mentioned above. It also accepts the optionalparameter sFeatures, which is used to specify position information onscreen, and is identical to the parameter of the same name in theshowModalDialog method in the DOM.

[0624] The second method passes a string specifying a point name. Inthis method, the showFaceplate call is responsible for determining whichfaceplate to invoke, removing the need for the user to call getFaceplateseparately.

[0625] The third method also removes the need for a separate call togetFaceplate. In this case, an object in the DOM is passed as aparameter, instead of a string specifying a point name. Again, the datasource connector is responsible for determining which faceplate to show,and then invoking that faceplate.

[0626] Position management is an issue for faceplates in the TPA system,where faceplates move when the main display window is moved, minimisewhen the main window is minimised, and are constrained to the clientarea of the parent window. This is not an issue for most other systems(GUS utilizes its own desktop management system in SafeView, forexample, and PlantScape conforms to the standards used in Microsoftproducts, where a modeless push-pinned dialog is moved independently ofits parent window). For a system utilizing a large number of faceplatesdisplayed at any one time, however, such as TPA, these solutions are notsufficient, and some form of position management system is required.

[0627] Almost any type of faceplate window behaviour can be achieved, aslong as the faceplate window has access to the window handle of itsintended parent. If the faceplate declares itself as an MDI childwindow, it will behave as such, even if the parent is not an MDIapplication. This is the case for TPA faceplates. If the faceplatedeclares itself as a normal child window, it will minimize with theparent window, but not be constrained to the parent client area. And ifthe faceplate is a normal window, but sets its parent window to thecalling display, it will minimize with the parent, but not beconstrained to the parent client area, and move independently of theparent.

[0628] The key to this functionality is obtaining the window handle(HWND) of the application containing the calling display. This is simplein the operator environment, as the data source component (which createsthe faceplate in its showFaceplate method) is able to obtain this windowhandle from the framework. In the browser environment, however, this isnot possible. This constitutes yet another differentiator between thetwo environments—faceplates are not as easy to manage in the browserenvironment. As faceplates are generally associated with process-controltype functions, this is an acceptable compromise.

[0629] The mechanism used by the data source connector to set the parentwindow on the invoked faceplate is simply as a property set on thefaceplate object—it must expose the parentHWND property to be set by thedata source connector. It is up to the faceplate object to decide how ituses this window handle, which in turn dictates its behaviour. (It willbe quite feasible to build a generic faceplate container, which dependson information in the individual faceplate HTML definition to decidewhich behaviour to exhibit. Thus TPA faceplates could functiondifferently from PlantScape faceplates, while still using a singlefaceplate container window).

[0630] Lifetime management of faceplates is an issue in the case of thepushpin functionality required by the TPA system. Normally, when afaceplate is invoked, it is destroyed when the operator changesdisplays. If the faceplate is “pinned”, however, it will remain visibleacross page changes. If it is subsequently “unpinned”, the next pagechange will destroy the faceplate. The mechanism used in Hendrix toinform faceplates of page changes is as follows:

[0631] 1. The data source connector on each page retains pointers toeach faceplate object it has invoked.

[0632] 2. Upon page change, the data source connector informs each ofthese faceplates that the page is changing.

[0633] 3. The faceplates return a result to the data source connectorindicating whether they have destroyed themselves or not, depending ontheir pushpin state.

[0634] 4. The data source connector updates its array of pointers toindicate the remaining faceplates, then persists this information sothat it can be retrieved by the data source connector on the newdisplay. (The ability to persist COM pointers across page changes isalready possessed by the data source connector, as connectioninformation also needs to be persisted across page changes, so that anew page can connect to the same data source as the previous page).

[0635] 5. The data source on the new page retrieves the pointers to thefaceplates it needs to manage, so that it can subsequently inform themwhen it is being destroyed.

[0636] Preferences, where they pertain to faceplates, concern theability of an operator to define a set of faceplates that they want tobe called up each time a particular display is invoked. This is done ina similar way to the lifetime management of faceplates. The data sourceconnector on a page already retains an array of pointers to thefaceplates it has invoked. When asked to persist preference information,it requests configuration information from these faceplates (such asposition, point name, etc.), then persists this information in astructured XML data store. This information is stored on a per-user,per-display basis. It then exposes a method, showPreferenceFaceplates,which will retrieve this information and invoke the faceplates, in therequired positions, as required.

[0637] In summary, then, the last three functionalities impose certainrequirements on both the data source connector and the faceplate objectas used in the preferred embodiments. These requirements are as follows:

[0638] The faceplate object must expose the queryDestroy method, whichis called by the data source connector when it is being unloaded. Thismethod returns a value indicating whether the faceplate did, in fact,destroy itself. (The faceplate must also expose a destroy method, whichdestroys the faceplate regardless of pushpin state.)

[0639] The data source connector must expose theshowPreferenceFaceplates method.

[0640] The data source connector must expose thepersistFaceplatePreferences method, which will cause it to query allopen faceplates for their position information, and store thisinformation in structured XML data.

[0641] The faceplate object must expose methods which returnsconfiguration information (such as current position on screen, as set bythe operator, and current point name). The data source connector callsthese methods when storing faceplate preferences.

[0642] The faceplate object must expose the parentHWND property, which,when set, it will use to create itself as a child of that window.

[0643] The following features are set out to provide the addressee withsome additional insight into the architecture of the preferredembodiments.

[0644] IHendrixBinding [ object,uuid(11877500-CA13-11D2-B6EA-00C04FF010A0) ] interface IHendrixBinding :IUnknown {   // TBD };

[0645] IHendrixBinding is implemented by the binding engine's internalbinding objects.

[0646] IHendrixBindingEngineCache [ object,uuid(11877501-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixBindingEngineCache : IUnknown {   HRESULT Flush( );   HRESULTQueryMode([out]BOOL *pbCacheOn);   HRESULT SetMode([in]BOOL bCacheOn);};

[0647] IHendrixBindingEngineCache is implemented by the Hendrix databinding engine to allow data sources to control the binding engine'stransmission cache. This cache is used to buffer updates to the displaypage to minimize round trips between the binding engine and the displaypage.

[0648] IHendrixCollection [ object,uuid(11877502-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixCollection : IDispatch { };

[0649] IHendrixCollection is implemented by collection subobjects. It isan empty interface used as a type indicator for the binding enginenavigating the object model via IHendrixDataRef

[0650] IHendrixConnectionPoint [ object,uuid(11877503-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixConnectionPoint : IUnknown {   HRESULT Connect([in] riid,    [in, iid_is(riid)]IUnknown *pNotifySink,     [out]DWORD *pdwCookie);  HRESULT Disconnect([in]DWORD dwCookie); };

[0651] IHendrixConnectionPoint is an improved version of the standardconnection point mechanism. It requires only one transaction toestablish the connection.

[0652] IHendrixDataRef [ object,uuid(11877504-CA13-11D2-B6EA-00C04FF010A0) ] interface IHendrixDataRef :IDispatch {  typedef struct  {   REFIID riid;   [iid_is(riid)]IUnknown*pSubObject;  } SUBOBJ;  HRESULTGetSubObjectsOfNames([in,size_is(cNames)]  OLECHAR **rgszNames,[in]unsigned int cNames, [in]LCID lcid, [out,size_is(cNames)] SUBOBJ*rgSubObjects); };

[0653] IHendrixDataRef is implemented by objects in the data sourceobject model. It is an extension of the standard IDispatch interfacethat allows the object hierarchy to navigated more quickly.

[0654] IHendrixDataSource [ object,uuid(11877505-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixDataSource : IUnknown { HRESULTInit([in]IHendrixBindingEngineCache *pCache, [in]IStream*pBindingDefStream, [out]IHendrixDataRef **ppDataSourceRoot); HRESULTStart( ); HRESULT Stop( ); };

[0655] IHendrixDataSource is the main interface exposed by a datasource. It allows the data source manager to initialize, start and stopthe data source.

[0656] IHendrixDataSourceManager [ object,uuid(11877506-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixDataourceManager : IUnknown {  //TBD };

[0657] IHendrixDataSourceManager is the main interface exposed by thedata source manager. It is used primarily by the data source connectorin the display page and by any run time frameworks managing displaypages.

[0658] IHendrixNotifySink [ object,uuid(11877507-CA13-11D2-B6EA-00C04FF010A0) ] interfaceIHendrixNotifySink : IUnknown {  HRESULT OnChange([in]DISPID dispid,   [in]VARIANT newVal); };

[0659] IHendrixNotifySink is implemented by the binding engine'sinternal binding objects. It is used by data reference objects to notifythe binding engine of changes to property values.

[0660] The next part of this document provides a description of theHendrix data source architecture. In particular, it describes thecomponents and interactions relevant to any data source implementation.There is provided an overview of the architecture and how data sourcesrelate to the rest of the Hendrix architecture as well as a descriptionof the components that comprise a data source in detail includingrequired interfaces and interactions with other components.

[0661] This document focuses on the implementation of Hendrix datasources. A data source is a component that exposes data, events andmethods provided by a specific server system to the Hendrix data bindingengine. The data binding engine then provides the means by which thesedata, events and methods are bound to the presentation elements in adisplay page.

[0662] A data source provides a means of encapsulating all of themechanisms required to access a server system from an HMI. Itencapsulates the mechanisms for establishing and securing connections toa server system, delivering data to and from a server system, deliveringevents from the server system to the HMI and invoking methods on theserver system from the HMI.

[0663] A data source implementation of the preferred embodimentsactually consists of two main parts. The first is the data sourcecomponent itself, which is responsible for the overall operation of thedata source such as establishing connections to server systems andpersistence of the data source. The second part is a hierarchy of dataobjects, called the data object model, which exposes the server systemdata, events and methods to the Hendrix data binding engine. The datasource component also acts as the root of the data object model. FIG. 27illustrates the general arrangement of the Hendrix data sourcearchitecture.

[0664] A Hendrix user interface framework hosts one or more displaypages. A user interface framework uses the services of a Hendrix datasource manager to manage a set of data sources that supply data to thedisplay pages it hosts. The data source manager provides an executionenvironment for data sources that includes a number of services thatthey require in order to provide efficient, secure access to data.

[0665] Hendrix data sources, as used in the present embodiments, arein-process COM objects. They belong to the Honeywell Data Sourcecomponent category identified by the following GUID.

[0666] CATID_HDXDataSource={E2156A20-640F-11d3-B766-00C04FF010A0}

[0667] This component category is used by interested parties (e.g. theHendrix display builder) to learn what data source implementations areavailable on a system.

[0668]FIG. 28 illustrates the components that constitute a data source,the main COM interfaces they implement and the main relationships theyhave with other parts of the Hendrix architecture.

[0669] The only externally createable object in a data sourceimplementation is the data source factory. The data source factory is aregular COM object (not a class object) that is used to manufactureinstances of a particular data source implementation. The data sourcefactory is cached by the data source manager for the lifetine of thedata source manager and provides an opportunity for a data sourceimplementation to share resources such as network connections betweendata sources (concurrently and serially). A regular COM object is usedrather than a COM class object to enable data sources to be implementedin Visual Basic. The data source factory implementsIHDXDataSourceFactory, which is used to manufacture a new data sourceinstance.

[0670] The main COM interfaces implemented by a data source areIHDXDataSource and IHDXDataObject. IHDXDataSource allows the data sourcemanager to access the methods that control the overall operation of thedata source. IHDXDataObject allows the data source manager to access themethods used to control individual data objects in the data objectmodel.

[0671] Data sources and data objects implement a number of other COMinterfaces to complete the functionality required by the data sourcemanager and clients of the data source manager. These interfaces aredescribed in further detail below.

[0672] Hendrix data sources expose a set of standard properties thatcontrol their behaviour in various circumstances. There are currentlytwo standard properties defined, these are “SimulatedData” and“QualityOfService”.

[0673] SimulatedData is a boolean property whose value indicates whetheror not the data source should deliver real or simulated data. Typically,SimulatedData is set to TRUE when the client of the data source manageris the Hendrix Display Builder and set to FALSE when the client of thedata source manager is a run time framework.

[0674] QualityOfService is an enumeration that indicates to the datasource what quality of service is desired. Control room operators wouldtypically require a high quality of service, while a lower quality ofservice might be adequate for more casual users.

[0675] It is up to each data source implementation to decide exactly howit will respond to the various values of these properties. It isexpected that this set of properties will expand over time and thearchitecture allows for this expansion. More information on standarddata source properties is provided below.

[0676] Each data source has a site object through which it accesses avariety of services. These services are exposed as a set of ambientproperties accessible via IDispatch on the site object. The servicesprovided by the site object currently include a data transfer service, asecurity service and an error logging service.

[0677] The data transfer service allows a data source to register dataobjects with the Hendrix binding engine and to control the transfer ofdata through the binding engine. The data transfer service is accessiblethrough the “DataTransfer” ambient property. Additional details on thedata transfer service are provided below.

[0678] The security service allows a data source to discover thecredentials of the user currently logged on to the user interfaceframework and to receive notifications of changes to those credentials.The credentials are available through the “Username” and “Password”ambient properties and the notification service is available through the“Security” ambient property. Further details about the security serviceare provided below.

[0679] The “Error” ambient property can be used to access the errorlogging service, and is described further below.

[0680] The data object model is the means by which a data source exposesindividual server system data items to the Hendrix data binding engine.Each data object is in essence a conduit through which data and eventsare delivered from the server system to the user interface and data andmethod invocations are delivered to the server system from the userinterface. Data objects are arranged in a hierarchy rooted at the toplevel data source object.

[0681] Data objects typically have a set of properties that control whatdata is to be delivered and how to deliver that data and are referred toas configuration properties. The set of configuration propertiesconstitutes the persistent state of a data object and a data objectprovides property pages to allow these configuration properties to beconfigured. The most common client of these property pages will be theHendrix display builder. Configuration properties typically include thename of the server system data item to be delivered by the data object.The IHDXName interface is used as an abstraction of the details requiredto specify such names.

[0682] Data objects also have a set of properties that expose the actualserver system data that is to be bound to a display page. Theseproperties are referred to as dynamic properties. Dynamic propertiesalso support data binding (that is, they are marked as [bindable] in atype library). This means that a data object will issue a propertychange notification via IPropertyNotifySink whenever a dynamic propertychanges.

[0683] Some properties belong in both sets, that is, they are used toconfigure the delivery of data in the builder and are bound to a displaypage at run time.

[0684] A data object also defines an outgoing interface if it supportsevents. Events are fired into the binding engine using an implementationof IDispatch provided by the binding engine.

[0685] Since many server systems contain different types of data items,data object models contain different types of data objects. These typesexpose the data, events and methods relevant to the various types ofunderlying server system data items. Data object types are identifiedusing a syntax similar to COM programmatic IDs (progIDs).

[0686] The number and type of data objects in an instance of a dataobject model are generally determined by the data requirements of theparticular display page that the instance services. The user determinesthese requirements as the display page is constructed.

[0687] The actual interface between data objects in a data source andthe Hendrix data binding engine is based on the standard COM Automationmechanism. This makes it relatively easy to build data objects usingstandard COM enabled tools such as ATL, Visual Basic and J++.

[0688] In addition to the configuration and dynamic properties discussedabove, a data source also provide properties and methods for navigatingthe data object model. This enables the data object model to be scriptedusing standard ActiveX scripting engines.

[0689] The following automation compatible types are used for propertiesand method or event arguments on data objects.

[0690] VT_UI1, VT_I2, VT_I4, VT_R4, VT_R8, VT_CY, VT_DATE, VT_BSTR,VT_VARIANT, VT_BOOL, VT_NULL, VT_ERROR

[0691] Safe arrays of these types are also supported (that is,VT_ARRAY|*). BY_REF properties are not supported.

[0692] There are two general cases in which a data source will bepersisted. The first is saving the configuration of the entire datasource to allow efficient reloading at a later time. The most commonscenario will be saving the data source configuration after the datasource has been modified by the Hendrix display builder and then loadingthe configuration when a display page is called up in an operatorframework.

[0693] The second case is when individual objects in a data source arepersisted independently of one another. This occurs primarily when theHendrix display builder is performing clipboard operations such as cut,copy and paste.

[0694] The first case requires that there be an implementation ofIPersistStreamInit that saves and loads the entire data source state toand from a stream provided by the data source manager. Performance is ofparamount importance in this case so data sources should use a streamformat that allows them to load as quickly as possible. This formatoften contains additional information derived during data sourcevalidation in order to facilitate speedy loading.

[0695] The second case requires that all data objects in a data sourcesupport the persistence interfaces IPersistStreamInit as a minimum andpreferably IPersistPropertyBag. In this case performance is not ascritical and any convenient stream format is used.

[0696] Since all data objects including the root data object arerequired to implement persistence interfaces to support clipboardoperations there needs to be a separate implementation ofIPersistStreamInit that is used to serialize the entire data source.This implementation is retrieved via a call toIHDXDataSource::GetPersistenceHelper.

[0697] Data objects exist to deliver data from server systems. Animportant part of configuring a data object to deliver data is thespecification of exactly what data to deliver. It is important torealize that the identity of the data object is not the same as theidentity of the server system data item that it delivers to the bindingengine.

[0698] Many data objects are associated with one and one only serversystem data item. In this case there is a single name property on thedata object. It is also possible for a data object to have more than oneserver system name associated with it. An example of this might be adata object that provides an array of historical data for a number ofpoint parameters. In this case there would be one name property for eachpoint parameter. Such a data object might be used to drive a trendobject.

[0699] Typically, the user of the Hendrix display builder provides thesenames. Before a user enters a name the user has to discover what namesare available and then choose one. The two main mechanisms for this areto “remember and type” or to provide a namespace browser mechanism thatallows the user to navigate a server system's namespace and select namesdirectly from that namespace.

[0700] In either case, the process is greatly assisted by providingknowledge of the type of named object required. For example, if a dataobject is designed to deliver PlantScape point parameter data, thebrowser is constrained to show only names of PlantScape pointparameters.

[0701] The IHDXName interface is designed to encapsulate both a serversystem name and the type of the named object. A data object thatrequires server system names as part of their configuration exposes oneor more sub-objects that expose the IHDXName interface. The builder usesIHDXName::get_Type to constrain the namespace browser or prompt theuser. [IDXName::put_Name is then used to set the name.

[0702] When data objects are arranged in a hierarchy, the nameproperties on the data objects are preferably partial names that, whentaken together, form a complete name. In such a case IHDXName::get Namewould return the partial name and IHDXName::get_FullName would returnthe complete name up to that point in the hierarchy.

[0703] Since a user's primary interest is not in the names of the dataobjects but in the names of the server system data items that theydeliver, there needs to be a way of mapping from server system namesback onto data objects. This is required when a user wants to access adata object from script code and will probably not even be aware of theidentity of the data object itself. In this case the user supplies thename of the server system data item and the system queries the dataobjects for one that knows about the requested name.

[0704] IHDXDataObject::GetPrimaryName is provided to allow the bindingengine to query a data object for the name most likely used by a user toidentify it. In the case of data objects with a single name property itis simply that single name property that is returned. In the case of adata object with more than one name property, the data object nominatesone of these to be the primary name.

[0705] The following part of the specification describes the interfacesthat are implemented on data sources and data objects. Particularly, thefollowing table lists the interfaces implemented by Hendrix datasources. INTERFACE OPTIONAL IHDXDataSource No IHDXDataObject NoIHDXDataSourceValidation Yes IHDXSecurityNotify Yes IObjectWithSite YesIdispatch Yes IProvideClassInfo2 Yes ISpecifyPropertyPages YesIPerPropertyBrowsing Yes IPersistStreamInit Yes IPersistPropertyBag YesISupportErrorInfo Yes

[0706] IHDXDataSourceValidation is only required by data sources thatsupport the validation of their configuration.

[0707] IHDXSecurityNotify is only required by data sources that need tobe kept informed of changes to the current user's security credentials.

[0708] IDispatch, IProvideClassInfo2, ISpecifyPropertyPages andIPerPropertyBrowsing are required only if the data source object itselfhas persistent build mode properties.

[0709] IPersistStreamInit or preferably IPersistPropertyBag is requiredif the data source object has any persistent configuration properties.

[0710] ISupportErrorInfo is optional but the data sources of thepreferred embodiments implement this interface so that they providedetailed error information to the data source manager in the event thata method in one of the above interfaces fails.

[0711] The following table lists the interfaces implemented by Hendrixdata objects. Interface Optional IHDXDataObject NoIConnectionPointContainer Yes IConnectionPoint Yes IDispatch YesIProvideClassInfo2 Yes ISpecifyPropertyPages Yes IPerPropertyBrowsingYes IPersistStreamInit Yes IPersistPropertyBag Yes ISupportErrorInfo Yes

[0712] The only mandatory interface on a data object is IHDXDataObject.If the data object does more than simply contain other data objects itwill need to implement some or all of the other interfaces listed above.

[0713] Data objects that deliver data to the Hendrix data binding engineimplement IConnectionPointContainer, IConnectionPoint, IDispatch andIProvideClassInfo2.

[0714] ISpecifyPropertyPages and IPerPropertyBrowsing are required onlyif the data object has configuration properties.

[0715] IPersistStreamInit or preferably IPersistPropertyBag is requiredif the data source object has any persistent configuration properties.

[0716] ISupportErrorInfo is optional but it is recommended that datasources implement this interface so that they provide detailed errorinformation to the data source manager in the event that a method in oneof the above interfaces fails.

[0717] This following part of the specification describes the generaloperation of Hendrix data sources. Two common scenarios are consideredin detail. Firstly, data source operation when the client of the datasource manager is an operator framework is considered followed by thecase where the client of the data source manager is the Hendrix displaybuilder.

[0718] Note that these are two common scenarios, not the only possiblescenarios. For example, in other embodiments, the Hendrix builder isconnected to and starts a data source to provide a live preview mode.

[0719]FIG. 29 illustrates the typical data source states and the methodsthat cause transitions between those states when a data source is beingused to provide data to a run time UI framework. This is also referredto as run mode operation. FIG. 30 is a UML sequence diagram thatillustrates the basic operation of a Hendrix data source at run time inmore detail.

[0720] Data source initialisation commences with the initialisation ofthe top level component with calls IObjectWithSite::SetSite andIPersistStreamInit::InitNew or IPersistPersistStreamInit::Load. Duringinitialisation, the root object is registered with the data bindingengine using IHDXDataTransfer::RegisterDataObject. IHDXDataTransfer isaccessible through the “DataTransfer” ambient property on the siteobject. Once the root object has been initialised, the data sources arefully initialised via the persistence helper object.

[0721] Connection is initiated via a call to IHMXDataSource::Connect.The process of connecting to a server system can fail, and thistypically occurs for one of two reasons. The first is that there is aproblem establishing a connection to the server system. This might bedue to network or configuration problems. The second reason forconnection to fail is that the current user does not have authority toview the data provided by the data source. The check to verify that auser is authorised to use a data source is typically performed by usinga combination of the current user's username and some configurationproperties of the data source. For example, a data source providingproperties that restrict its use to a particular plant area. Duringconnection, the data source checks that the current user is a member ofthe specified area. If the check fails then the data source returns anerror code that distinguishes this authorisation failure from moregeneral connection failures.

[0722] When the data source manager encounters an authorisation failurein one of the data sources for a display page, the initialisation of alldata sources for the display page is aborted and the user interfaceframework is alerted to the fact.

[0723] Once a data source has been successfully connected it is started.Prior to IHDXDataSource::Start being called, the data binding enginewill have hooked each registered data object up to a sink object thatwill receive property change notifications and events from it. Thishookup is performed using the standard IConnectionPoint mechanism.

[0724] IHDXDataSource::Start is a signal to the data source to begindelivering data by calling IPropertyNotifySink::OnChanged and honouringthe subsequent call to IDispatch::Invoke by the binding engine toretrieve the changed property value.

[0725] Events are fired into the binding engine by a data object usingIDispatch::Invoke.

[0726] The data source calls IHDXDataTransfer::Flush to have dataupdates propagated to the display page. This mechanism allows a datasource to accumulate a batch of data updates before having them appliedto the display page in a single transaction, thus greatly improvingperformance of the data transfer mechanism. IMXDataTransfer::Flush isimplicitly called whenever an event is fired by a data source. Thisensures that the state of the page is up to date when the display pagemethod that the event is bound to is called.

[0727] When the data source is no longer required, it will first bestopped with a call to IHDXDataSource::Stop. The data source is thenrestarted by another call to IHMXDataSource::Start or un-initialisedwith a call to IHDXDataSource::Uninitialise.

[0728] During IHDXDataSource::Uninitialise the data source shouldun-register its data objects and release the data source site object.

[0729] One of the main jobs of the Hendrix display builder is toconstruct and configure data sources for later use in a run time UIframework. FIG. 31 illustrates the typical data source states and themethods that cause transitions between those states when a data sourceis being used by the Hendrix display builder. This is also referred toas run mode.

[0730] The main causes of state transitions in build mode are changes tothe configuration of data source properties. This is indicated by thecalls to IDispatch::Invoke in the state transition diagram, althoughcalls to IHDXDataObject::CreateObject and IHDXDataObject::DeleteObjectcause similar transitions. These calls occur as the user interacts withthe builder to modify the configuration of the data sources for adisplay page.

[0731] In build mode, the “Loaded” is also used as a dirty state, inwhich the data source configuration contains changes that have not beensaved.

[0732] The “Validation” state is only applicable to data sources thatimplement IHDXDataSourceValidation. The call toIHDXDataSourceValidation::Validate is a signal to the data source to dowhatever it has to do to check that the current configuration is valid.This step is also used to generate additional information that is usedinternally within the data source at run time if the process ofgenerating this information is too time consuming to be done during thefrequently called IPersistStreamInit::Save method.

[0733]FIG. 32 is a UML sequence diagram that describes a build modesequence of events in which a new data source is created and configuredto have a simple data object model consisting of a root data objectcontaining one child data object.

[0734] In this scenario, initialisation consists of calls to andIObjectWithSite::SetSite and IPersistStreamInit::InitNew. Duringinitialisation the data source registers the root data object.

[0735] After instantiation and initialisation the data object model isconstructed. Object model construction commences at the root object.Data objects (other than the root object) are created by calls toIHDXDataObject::CreateObject( ) on the container of the new data object.As a data object is able to contain data objects of different types, aparameter in the IHDXDataObject::CreateObject( ) call identifies thetype of data object to create. The builder retrieves a list of typessupported by a container by calling IHDXDataObject::GetCreatableTypes.As an example, the type of a PlantScape data object that delivers apoint parameter is “PlantScape.PointParam”.

[0736] IHDXDataObject::CreateObject returns an ID that is later used toremove the data object with a call to IHDXDataObject::DeleteObject. ThisD is assumed to be unique within the data object model and persistent.It is also used in the call to IHDXDataTransfer::RegisterDataObject.

[0737] To construct a configuration user interface, the builder uses thestandard interfaces IDispatch, IProvideClassInfo2, ISpecifyPropertyPagesand IPerPropertyBrowsing on individual data source objects.

[0738] Once the data object model has been constructed and configured,it is validated via a call to IHDXDataSourceValidation::Validate andsaved with a call to IPersistStreamInit::Save. Validation, in someembodiments, requires that a transient connection to a server system beestablished. It is the responsibility of the data source to save thestate of the data source component as well as all of the objects in thedata object model.

[0739] There are two additional services available to data sources thatassist their operation. The first of these is the security service. Thesecurity service provides access to the current user's username andpassword via the “Username” and “password” ambient properties. Thesecredentials are used to secure a data source in any way that isappropriate to a particular data source. It is up to each data source toverify that these credentials are authentic.

[0740] In addition, a data source is registered with the securityservice to receive notifications of changes to these credentials bycalling IHDXSecurity::Advise. IHDXSecurity is accessible through the“Security” ambient property. The data source will be notified of changesthrough a call the IDXSecurityNotify interface implemented by the datasource.

[0741] The second additional service is a logging service that allowsdata sources to write diagnostic and error messages to a central logmaintained by the data source manager. IHDXError::LogError is used towrite messages to the log. IHDXError::RaiseError logs the error in thelog file and propagates the error to the user interface framework. Eachmessage is assigned a severity level that is used to filter the writingof messages to the log. IHDXError is accessible through the “Error”ambient property.

[0742] Hendrix data sources are implemented using any tool that allowsyou to construct COM objects with the required interfaces. Two commonchoices will to write them in C++ using Microsoft's Active TemplateLibrary or in Microsoft's Visual Basic. It is also be possible to writea Hendrix data source in Java using Microsoft's J++.

[0743] The Hendrix SDK includes two sample data source implementations,one in C++ using ATL and the other in Visual Basic. ATL's fine grainedapproach to COM object implementation makes it possible to pull togethera data source and data object implementation from the individualimplementations of standard COM interfaces provided by ATL. The onlyinterfaces for which there are no built in implementations areIHDXDataSource, IHDXDataSourceValidation, IHDXSecurityNotify,IHDXDataObject and IHDXName.

[0744] If a data source exposes a complex data object model, requireshigh performance operation or wishes to perform complex internalresource management, C++ and ATL are the best implementation strategy.

[0745] Many of the interfaces required on a Hendrix data source are asubset of the interfaces on an ActiveX control. This means that oneimplementation strategy is to implement the data source and data objectsas ActiveX controls. Visual Basic makes it easy to construct a Hendrixdata source out of ActiveX controls.

[0746] All that needs to be done is to import the Hendrix Data Sourcetype library and implement an ActiveX control for the data source and anActiveX control for each type of data object in the data source.Implementations of IHDXDataSource, IHDXDataSourceValidation,IHDXSecurityNotify, IHXDataObject and IHDXName are then added to thecontrols, as required.

[0747] The Hendrix data source manager is free threaded, that is, itexecutes in a COM Multithreaded Apartment (MTA). The data transfermechanism between a data source and the Hendrix data binding engineinvolves a great many method calls, especially if the data sourcesupports a complex data object model. For this reason, in thoseembodiments where the data sources require high performance, they arewritten so that they can also execute in an MTA. This means that theyneed to be thread safe and marked in the registry as ThreadingModel=Bothor ThreadingModel=Free.

[0748] It is possible to build a single threaded data source but itsperformance will be less than that of a multithreaded data source due tothe presence of an apartment boundary between the data source and therest of the data source manager. This may not be a serious limitationfor many simple data sources.

[0749] This part of the document details the COM interfaces, standardand ambient properties and enumerations relevant to the implementationof a Hendrix data source. The header file containing these definitionsfor C++ developers is called HDXDS.H and the type library for VisualBasic developers is called HDXDS.TLB. These files are included in theHendrix SDK.

[0750] The preferred Hendrix data source interfaces are set out below.

[0751] IHDXDataObject IHDXDataObject is implemented by all data objectsin a data source's data object model. interface IHDXDataObject :IUnknown { HRESULT CreateObject([in]BSTR bstrType, [in, out] long*plID), [out, retval] IDispatch** ppNewObject); HRESULT DeleteObject([in]long lID); HRESULT GetParent([out, retval] IDispatch** ppParent);HRESULT GetID([out, retval] long* plID); HRESULT GetType([out, retval]BSTR* pbstrType); HRESULT GetCreatableTypes([out, retval]SAFEARRAY(BSTR)* pTypes); HRESULT GetPrimaryName([out, retval]IHDXName** ppName); }; IHDXDataObject::CreateObject Creates a new dataobject as a child of the current object. HRESULT CreateObject([in] BSTRbstrType, [in, out] long* plID, [out, retval] IDispatch** ppNewObject);Parameters: bstrType The type of the data object to create. plID Theaddress of where to store the ID used to subsequently identify the dataobject. This ID is generated by the data source. PpNewObject  Areference to the newly created data object. Return Code: S_OK The methodsucceeded. HDX_E_INVALIDTYPE The container does not support therequested type of data source object. HDX_E_NOTCONTAINER The data objectis not a container and cannot be used to create further data objects.E_FAIL The method failed. The ID returned from this function is used incalls to IHDXDataObject::DeleteObject,IHDXDataTransfer::RegisterDataObject andIHDXDataTransfer::UnregisterDataObject. The ID needs to be persistent.The newly created data object is registered with the Hendrix databinding engine using IHDXDataTransfer::RegisterDataObject prior to thismethod returning. IHDXDataObject::DeleteObject Deletes the specifieddata object. HRESULT DeleteObject([in]long lID); Parameters: lID The IDof the object to be deleted. Return Code: S_OK The method succeeded.HDX_E_OBJECTNOTFOUND The requested data object did not exist. I.e. theID was not valid. HDX_E_NOTCONTAINER The data object is not a containerand cannot container other data objects. E_FAIL The method failed. Ifthe data object being deleted is a container object then all containedobjects are to be implicitly deleted as well. Prior to being deleted,data objects must be unregistered with the Hendrix data binding engineusing IHDXDataTransfer::UnregisterDataObject. IHDXDataObject::GetParentReturns the parent of the data object. HRESULT GetParent([out, retval]IDispatch** ppParent); Parameters: ppParent Pointer to the IDispatchinterface on the data object's parent. Return Code: S_OK The methodsucceeded. HDX_E_NOPARENT The data object does not have a parent. Thiswould be returned if IHDXDataObject::GetParent was called on the rootobject. E_FAIL The method failed. IHDXDataObject::GetID Returns the IDof the data object. HRESULT GetID([out, retval] long* plID); Parameters:plID Pointer to the location in which to store the ID of the dataobject. Return Code: S_OK The method succeeded. E_FAIL The methodfailed. The ID returned by this method is the same ID returned byIHDXDataObject::CreateObject. IHDXDataObject::GetType Returns the typeof a data object. HRESULT GetType([out, retval]BSTR *pbstrType);Parameters: pbstrType The type of the data object. Return Code: S_OK Themethod succeeded. E_FAIL The method failed.IHDXDataObject::GetCreatableTypes Returns a list of the types supportedby a container object. HRESULT GetCreatableTypes([out, retval]SAFEARRAY(BSTR)* pTypes); Parameters: pTypes A safe array of BSTRscontaining the types of objects that can be created by the data object.Return Code: S_OK The method succeeded. HDX_E_NOTCONTAINER The datasource object is not a container object, and cannot be used to createfurther data objects. E_FAIL The method failed.IHDXDataObject::GetPrimaryName Returns the primary name of the dataobject. HRESULT GetPrimaryName([out, retval]IHDXName **ppName);Parameters: ppName Pointer to the IHDXName interface on the dataobject's primary name. Return Code: S_OK The method succeeded.HDX_E_NONAME The data source object does not have any names associatedwith it. E_FAIL The method failed. The primary name of a data object isthe server system name most likely to be used by a user to identify thedata object. IHDXDataSource IHDXDataSource is implemented by all Hendrixdata sources. interface IHDXDataSource : IUnknown { HRESULT Connect( );HRESULT Start( ); HRESULT Stop( ); HRESULT Uninitialize( ); HRESULTGetPersistenceHelper([out, retval]IPersistStreamInit **ppHelper); };IHDXDataSource::Connect Requests a data source to establish a connectionwith its data provider. HRESULT Connect( ); Parameters: None. ReturnCode: S_OK The connection was successfully established and the datasource can now be started. HDX_E_CONNECTFAILED The connection failed forsome reason other than a failure of authorisation. HDX_E_NOTAUTHORIZEDThe connection may have succeeded but the current user is not permittedto view the data provided by the data source.

[0752] Returning HDX_E_NOTAUTHORIZED means that the loading of thedisplay page for which the data source was to supply data will beaborted. This mechanism allows a data source to check the current useragainst criteria that is specified in the data sources persistent statein order to restrict data viewing to particular users.

[0753] IHDXDataSource::Start

[0754] Signals the data source object model to begin delivering data andevents. HRESULT Start( ); Parameters: None. Return Code: S_OK The methodsucceeded. E_FAIL The method failed. IHDXDataSource::Stop Signals thedata source object model to stop delivering data and events. HRESULTStop( ); Parameters: None. Return Code: S_OK The method succeeded.E_FAIL The method failed. A call to IHDXDataSource::Start might followthe call to IHDXDataSource::Stop. IHDXDataSource::UninitializeUn-initialises the data source object model. HRESULT Uninitialize( );Parameters: None. Return Code: S_OK The method succeeded. E_FAIL Themethod failed. The data source should release its references to the datasource site object in IHDXDataSource::Uninitialize.IHDXDataSource::GetPersistenceHelper Retrieves the implementation ofIPersistStreamInit used to persist the state of the entire data source.HRESULT GetPersistenceHelper([out, retval]IPersistStreamInit**ppHelper); Parameters: ppHelper The implementation ofIPersistStreamInit that persists the entire data source. Return Code:S_OK The method succeeded. E_FAIL The method failed.IHDXDataSourceFactory IHDXDataSourceFactory is implemented by a Hendrixdata source factory object. interface IHDXDataSourceFactory: IUnknown {HRESULT CreateDataSource([out] IHDXDataSource** ppDataSource); };IHDXDataSourceFactory::CreateDataSource Creates a new instance of thedata source. HRESULT CreateDataSource([out] IHDXDataSource**ppDataSource); Parameters: ppDataSource  Pointer to the newly createddata source. Return Code: S_OK The method succeeded. E_FAIL Theoperation failed. IHDXDataSourceValidation IHDXDataSourceValidation isimplemented by a Hendrix data source object model that supportsvalidation. interface IHDXDataSourceValidation: IUnknown { HRESULTValidate( ); HRESULT QueryNeedsValidating([out,retval]VARIAINT_BOOL*pbResult); }; IHDXDataSourceValidation::Validate Requests a data sourceto attempt validation. HRESULT Validate( ); Parameters: None. ReturnCode: S_OK The method succeeded. HDX_E_VALIDATEFAILED  Validationfailed. IHDXDataSourceValidation::QueryNeedsValidating Queries theobject model to determine if it needs to be validated. HRESULTQueryNeedsValidating([out,retval]VARIANT_BOOL* pbResult); Parameters:pbResult TRUE if the data source requires validation, FALSE otherwiseReturn Code: S_OK The method succeeded. IHDXDataTransferIHDXDataTransfer is implemented by Hendrix data source site object.interface IHDXDataTransfer : IUnknown { HRESULT FlushBuffer( ); HRESULTRegisterDataObject([in]long 1ID, [in]IUnknown *pDataObjectUnk); HRESULTUnregisterDataObject([in]long 1ID); }; IHDXDataTransfer::Flush Requeststhat Hendrix data binding engine flush all data updates accumulatedsince the last call to IHDXDataTransfer::Flush. HRESULT Flush( );Parameters: None. Return Code: S_OK The method succeeded.IHDXDataTransfer::RegisterDataObject Registers a data object with theHendrix data binding engine. HRESULT RegisterDataObject([in]long 1ID,[in]IUnknown *pDataObjectUnk); Parameters: 1ID The ID of the data objectbeing registered. pDataObjectUnk  A pointer to the IUnknown interface onthe data object being registered. Return Code: S_OK The methodsucceeded. E_FAIL The method failed.IHDXDataTransfer::UnregisterDataObject Un-registers a data object withthe Hendrix data binding engine. HRESULT UnregisterDataObject([in]long1ID; Parameters: 1ID The ID of the data object being unregistered.Return Code: S_OK The method succeeded. E_FAIL The method failed.IHDXError IHDXError is implemented by site objects to allow componentsto asynchronously generate error messages. interface IHDXError: IUnknown{ HRESULT RaiseError([in]BSTR bstrSource, [in]BSTR bstrDescription,[in]BSTR bstrHelpFile, [in]unsigned long ulHelpContext, [in]long 1Code);HRESULT LogError([in]BSTR bstrSource,   [in]BSTR bstrDescription, [in]long 1Code); }; IHDXError::RaiseError Used to notify the frameworkthat an error has occurred. HRESULT RaiseError([in]HDX_ERRORLEVEL level, [in]BSTR bstrSource, [in]BSTR bstrDescription, [in]BSTR bstrHelpFile,[in]unsigned long ulHelpContext,  [in]long 1Code); Parameters: level Theseverity of the error. See the HDX_ERRORLEVEL enumeration for details.bstrSource The source of the error. bstrDescription The description ofthe error. bstrHelpFile The help file for the error. ulHelpContext Thehelp file context for the error. 1Code The error code. Return Code: S_OKThe method succeeded. Errors raised with IHDXError::RaiseError arelogged in the Hendrix log file and propagated to the UI Framework.IHDXError::LogError Used to write an error message to the log file.HRESULT LogError([in]HDX_ERRORLEVEL level,  [in]BSTR bstrSource,[in]BSTR bstrDescription, [in]long 1Code); Parameters: level Theseverity of the error. See the HDX_ERRORLEVEL enumeration for details.bstrSource The source of the error. bstrDescription  The description ofthe error. 1Code The error code. Return Code: S_OK The method succeeded.Errors raised with IHDXError::LogError are logged in the Hendrix logfile and are not propagated to the UI Framework. IHDXName IHDXName isimplemented by data source objects. interface IHDXName: IDispatch {[propget, id(0)]HRESULT Type([out, retval]BSTR *pbstrType); [propget,id(1)]HRESULT Name([out, retval]BSTR *pbstrName); [propput,id(1)]HRESULT Name([in]BSTR bstrName); [propget, id(2)]HRESULTFullName([out, retval]BSTR *pbstrFullName); }; IHDXName::get_TypeReturns the type of a named server system data item. [propget,id(0)]HRESULT Type([out, retval]BSTR *pbstrType); Parameters: pbstrTypeThe type of the named server system data item. Return Code: S_OK Themethod succeeded. E_FAIL The method failed. IHDXName::get_Name Returnsthe name of a server system data item. [propget, id(1)]HRESULTName([out, retval]BSTR *pbstrName); Parameters: pbstrName The name of aserver system data item. Return Code: S_OK The method succeeded. E_FAILThe method failed. IHDXName::put_Name Sets the name of a server systemdata item. [propput, id(1)]HRESULT Name([in]BSTR bstrName); Parameters:bstrName The name of a server system data item. Return Code: S_OK Themethod succeeded. E_FAIL The method failed. IHDXName::get_FullNameReturns the full name of a server system data item. [propget,id(2)]HRESULT FullName([out, retval]BSTR *pbstrName); Parameters:pbstrName The full name of a server system data item. Return Code: S_OKThe method succeeded. E_FAIL The method failed. IHDXSecurityIHDXSecurity is implemented by the Hendrix data source manager.interface IHDXSecurity: IUnknown { HRESULT Advise([in]IHDXSecurityNotify*pNotifySink, [out, retval]long *p1Cookie); HRESULT Unadvise([in]long1Cookie); }; IHDXSecurity::Advise Establishes an advisory connectionwith the security service. HRESULT Advise([in]IHDXSecurityNotify*pNotifySink,  [out]long *p1Cookie); Parameters: pNotifySink A pointerto the IHDXSecurityNotify interface that is to receive securitynotifications. p1Cookie A cookie identifying the advisory connection.Return Code: S_OK The method succeeded. E_FAIL The method failed. Thecaller of IHDXSecurity::Advise( ) should remember the returned cookie sothat it can revoke the connection at a later time.IHDXSecurity::Unadvise Revokes an advisory connection with the securityservice. HRESULT Unadvise([in]long 1Cookie); Parameters: 1Cookie Acookie identifying the advisory connection. Return Code: S_OK The methodsucceeded. E_FAIL The method failed. IHDXSecurityNotifyIHDXSecurityNotify is implemented by a Hendrix data source componentthat needs to know about changes to the security access token. interfaceIHDXSecurityNotify: IUnknown { HRESULT OnCredentialChange( ); };IHDXSecurityNotify::OnCredentialChange Notifies the implementation ofchanges to the user's security credentials. HRESULT OnCredentialChange(); Parameters: None. Return Code: S_OK The method succeeded. Usercredentials consist of the user name and password. These credentials areaccessible via the Username and Password ambient properties. Therefollows some details on the Hendrix data source standard properties.SimulatedData Type VARIANT_BOOL

[0755] Description

[0756] Indicates whether real or simulated data is required from thedata source. If the value is TRUE then the simulated data is required.

[0757] A data source may respond to a value of TRUE by not generatingany data at all, if simulated data is too difficult to generate.

[0758] QualityOfService

[0759] Type

[0760] HDX_QUALITYOFSERVICE

[0761] Description

[0762] Indicates the desired quality of service to be provided by thedata source. Possible values are HDX_QUALITYOFSERVICE_LOW,HDX_QUALITYOFSERVICE_MEDIUM and HDX_QUALITYOFSERVICE_HIGH.

[0763] It is up to the data source implementation to determine if it ispossible to provide different levels of quality of service. Refer to theHDX_QUALITYOFSERVICE enumeration for further details.

[0764] The following is a description of the Hendrix data source ambientproperties. DataTransfer Type   IHDXTransfer* Description   Contains apointer to the IHDXTransfer interface. Error Type   IHDXError*Description   Contains a pointer to the IHDXError interface. PasswordType   BSTR Description   Contains the current user's username. SecurityType   IHDXSecurity* Description   Contains a pointer to theIHDXSecurity interface. Username Type BSTR

[0765] Description

[0766] Contains the current user's username.

[0767] The following is a description of the Hendrix data sourceenumerations.

[0768] HDX_DATASOURCE_ERROR_CODES HDX_DATASOURCE_ERROR_CODES enum {HDX_E_NOPARENT = −2147221504, HDX_E_NONAME = −2147221503,HDX_E_INVALIDTYPE = −2147221502, HDX_E_NOTCONTAINER = −2147221501,HDX_E_CONNECTFAILED = −2147221499, HDX_E_NOTAUTHORIZED = −2147221498,HDX_E_VALIDATEFAILED = −2147221497 } HDX_DATASOURCE_ERROR_CODES;

[0769] Description

[0770] Enumerates the Hendrix specific error codes returned by Hendrixinterface methods. HDX_ERRORLEVEL enum { HDX_ERRORLEVEL_INFO = 0,HDX_ERRORLEVEL_WARNING = 1, HDX_ERRORLEVEL_ERROR = 2 } HDX_ERRORLEVEL;

[0771] Description

[0772] Enumerates the severity levels for messages being written to thedata source managers message logging service. HDX_QUALITYOFSERVICE enum{ HDX_QUALITYOFSERVICE_LOW = 0, HDX_QUALITYOFSERVICE_MEDIUM = 1,HDX_QUALITYOFSERVICE_HIGH = 2 } HDX_QUALITYOFSERVICE;

[0773] Description

[0774] Enumerates the possible levels of quality of service that a datasource may be asked to provide.

[0775] For the benefit of the addressee, the description is now directedtoward an overview of the runtime used in the preferred embodiments.Firstly, this will require some explanation as to what constitutes aHendrix runtime. Hendrix is designed around providing users with twoways to view and control plant information: the operator environment,designed primarily for security and reliability, and the web browserenvironment, where universal, flexible, secure data access is the primeconcern. Development groups wishing to base their user interfaces on theHendrix architecture must develop components for both of theseenvironments; the combination of which is referred to jointly as aHendrix runtime.

[0776] In the operational environment, the runtime centres around theconcept of the operator framework (sometimes referred to as the operatorruntime framework).

[0777] In the web browser environment, the runtime centres aroundHendrix displays being rendered in Microsoft's Internet Explorer webbrowser, with the assistance of numerous Hendrix-specific componentswhich facilitate the connection to live process data. Some of thesecomponents are generic, and form part of the Hendrix toolkit that hasbeen developed by the Honeywell Software Center. Others, however, areproduct-specific and need to be implemented by each development groupindividually.

[0778] The Hendrix runtime, in both environments, consists of a numberof distinct components. FIG. 33 and FIG. 34 illustrate—for both theoperator framework and the browser environment—those components mostclosely related to the user interface itself Data-related components,such as Hendrix data sources manipulated by the Data Source Manager, aredealt with elsewhere in the Hendrix documentation set.

[0779] Note that some of the components are supplied by Microsoft aspart of the operating system, others components are part of the Hendrixtoolkit, while other components must be developed by each developmentgroup implementing a Hendrix runtime.

[0780] The responsibilities of the various components shown in FIG. 33and FIG. 34 are as follows:

[0781] Data Source Manager (DSM)

[0782] The Data Source Manager is responsible for managing data sourcesand connections, and for transferring data from data sources to elementson an HTML page via the page connector.

[0783] Framework

[0784] The operator framework corresponds to the application window (orwindows) interface artifacts such as toolbars and menus, which aretailored for the operational environment. It also provides desktopmanagement functionality, where appropriate, and participates in thelifetime management of the data source manager.

[0785] Browser Helper Object (BRO)

[0786] The browser helper object provides additional application-levelfunctionality to the browser, and fulfils the responsibilities that areotherwise handled by the framework in the operational environment. Itco-operates in the lifetime management of the data source manager, forexample, closing it when Internet Explorer itself is closed.

[0787] Shdocvw.dll

[0788] The shdocvw.dll provides the functionality of the web browsercontrol, which is used by both the framework and Internet Explorer forHTML rendering and navigation. This DLL uses MSHTML for the rendering ofHTML content. If a framework requires lower-level control over therendering process it optionally hosts MSHL directly.

[0789] Page Connector

[0790] The display page connector is placed on every Hendrix displayfile, and is responsible for managing the delivery of data to objects ona page. It is part of the Hendrix toolkit.

[0791] Urlmon.dll

[0792] Urlmon.dll is a system component responsible for assisting in thetransfer of remote data (such as HTML via HTTP) to applications whichrequire it. The web browser control uses urlmon.dll to download HTMLfiles.

[0793] Asynchronous Pluggable Protocol (APP)

[0794] Sitting on the other side of urlmon.dll is the HendrixAsynchronous Pluggable Protocol. This protocol is responsible forhandling page call-up security, path substitution to enable easy pagecall-up and to assist in internationalisation, and participating in theinstantiation of the data source manager. Its responsibilities arediscussed in detail below.

[0795] Running Object Table

[0796] The Running Object Table (ROT) is used to assist in theconnection of data source managers to the correct page connector in theruntime. This is to facilitate the ability to maintain communicationwith the data source manager across page changes. It is envisaged thatlater revisions of the architecture will require a custom object tofulfill this purpose, as a three-tier architecture may require greaterfunctionality than that provided by the ROT.

[0797] The preferred embodiments of the invention deal with implementingHendrix-compliant versions of the framework and the browser helperobject.

[0798] The Asynchronous Pluggable Protocol (henceforth referred to asthe APP) is part of the Hendrix toolkit. A description of APPs ingeneral can be found in the MSDN Library (under “Asynchronous PluggableProtocols Overview”). In essence, these are components responsible fordownloading information to be interpreted by the Internet Explorer webbrowser, the web browser control, or other internet-enabledapplications. Protocols are represented textually as the first part of aURL up to the colon, and are provided by the system for all majorprotocols:

[0799] ftp (e.g. ftp://ftp.microsoft.com)

[0800] file (e.g. file:c\debug.txt)

[0801] mailto (e.g. mailto:head.honcho@honeywell.com)

[0802] http (e.g. http://www.microsoft.com)

[0803] In the Hendrix architecture the APP implements the “page”protocol. Its main responsibilities revolve around page callup security,and path substitution, as follows.

[0804] All URLs to Hendrix pages (as created in the Hendrix builder) areof the form page://pagename (or page://pagename.htm). To browse directlyto a Hendrix page in Internet Explorer, typing a URL of this form issufficient. (Normal HTTP addresses are allowed well, but thearchitecture will redirect these pages so that they use the pageprotocol).

[0805] When a page URL is activated, the APP is invoked. Its firstresponsibility is to turn this URL into a fully-qualified URL. It doesthis by querying the framework for the current display search path, andthen locating the file within that search path. For example, if thecurrent search path is c:\Honeywell\displays\English, the URLpage://display1.htm will resolve toc:\Honeywell\displays\English\display1.htm.

[0806] This path substitution mechanism is intended to provide theframework with control over which displays are shown. The current pathdepends on the chosen operator language, the current department beingviewed, or other factors—it is completely up to the framework each timea page is called up.

[0807] APPs are inherently stateless, and must query the framework forthe search path each time a page is accessed. It obtains access to theframework through the ROT, as described later in this document.

[0808] Once the URL is fully resolved, the APP authenticates the user toensure the current operator has sufficient security privileges to callup the display. It does this by downloading (from the internet or localfile system) the relevant file and associated data binding definitions,and queries the DSM for permission to open the file. The APP obtainsaccess to the DSM through the ROT.

[0809] The DSM in turn attempts to activate the relevant data sourcesfor the file. If any of these fail due to insufficient securityprivileges, the DSM indicates to the APP that the operator is notallowed to view the file. The APP then passes no information to thebrowser, leaving the operator on the current page. If successful,however, the APP passes the HTML to the browser, and the page is calledup normally.

[0810] The interfaces which allow the framework to co-operate with theAPP in this way are described below.

[0811] This part of the specification discusses the main implementationstrategies for a Hendrix framework, and then details theresponsibilities of the framework, as far as the Hendrix architecture isconcerned. This functionality is divided into two sections: basic andadvanced. Basic functionality covers hosting the web browser control,instantiation of the Data Source Manager, and participation in the callup of Hendrix displays. Advanced functionality covers all other issuesconcerning the framework, such as participation in page callup security,popup windows, path substitution, error handling, security, andinternationalisation.

[0812] In essence, a Hendrix framework is any application capable ofhosting Microsoft's Web Browser Control (shdocvw.dll), which in turnplays host to the MSHTML rendering engine. The implication of this isthat any technology is conceivably useable to implement a Hendrixframework: Visual Basic, Microsoft Foundation Classes, the ActiveTemplate Library, etc.

[0813] For this reason, this detailed description does not concernitself with any one particular implementation strategy, but insteadfocuses on what functionality these frameworks must implement if theyare to participate in the Hendrix architecture. In some cases thedocument does present sample C++ ATL and/or MFC code, but this is forillustrative purposes only: it does not imply that this is the only waythis functionality is available to be implemented.

[0814] The MSDN Library and MSDN Online provide several excellentsamples illustrating how to host the web browser control, in varioustechnologies. These are listed below and the content thereof isincorporated herein by way of cross-reference. All samples listed (apartfrom MFCIE, which is in the MSDN Library) can be found as part of thedownload of IE5 headers and libraries from MSDN Online, athttp://msdn.microsoft.com/downloads/samples/internet/setup/entry.htm.

[0815] MFC

[0816] MFCIE sample, illustrating the use of the CHtmlView class.

[0817] The MFCIEEvtSpy sample, which illustrates how to sink InternetExplorer events.

[0818] The article “Creating a web browser-style application” in theMSDN Library

[0819] ATL

[0820] The AtlBrowser sample

[0821] Visual Basic

[0822] The VBWebBrowser sample, illustrating a full-functioned VB webbrowser.

[0823] The WBCustomizer sample, illustrating how to implement theIDocHostUIHandler interface from Visual Basic.

[0824] The DrillVB sample, which demonstrates how to traverse the DOMfrom an external application.

[0825] Framework Implementation

[0826] Upon application startup, the framework performs the followingtasks:

[0827] 1. Start the Data Source Manager

[0828] 2. Register a pointer to the running DSM in the Running ObjectTable. This is so that other Hendrix components (specifically, the PageConnector and the APP) are able to obtain access to the correct DSM,when required.

[0829] 3. Register a pointer to the framework itself in the ROT. Thisallows the APP to access the correct framework when it requests pathinformation.

[0830] These actions are discussed in greater detail below.

[0831] The following IDL is usually sufficient to indicate how the DSMis to be activated. [ uuid(9C657542-64B8-11D3-80D0-00C04F6847A2),helpstring(“HDXDataSourceManager Class”) ] coclass HDXDataSourceManager{ [default] interface IHDXDataSourceManager; };

[0832] Upon startup the framework simply needs to activate and bind tothis object. In ATL this may consist of little more than the followingline:

[0833] hr=m_spDSM.CoCreatelnstance(CLSID_HDXDataSourceManager),

[0834] As already described, the ROT is used to store references to arunning instance of the DSM for each instance of the framework (in somesystems multiple frameworks may be running simultaneously on a singlenode).

[0835] This system relies on the fact that in the Hendrix architecturethere is a one-to-one relationship between instances of the DSM andinstances of the framework. Each instance of the framework has a uniqueprocess ID, which is what is used to identify itself in the ROT.

[0836] The DSM is registered in the ROT by means of an item moniker. Thename of this item moniker takes the following format:

[0837] !HDX:DSM:pidscxxx

[0838] where xxxx is the process ID of the framework in question (e.g.1234).

[0839] The following code sample illustrates how registration may beperformed in ATL. CComBSTR bstrDelim(“!”); CComBSTRbstrItem(“HDX:DSM:pid=1234”); CComPtr<IMoniker> spMoniker; // create amoniker to the DSM hr = CreateItemMoniker(bstrDelim, bstrItem,&spMoniker); // now register it in the ROT CComPtr<IRunningObjectTable>spROT; GetRunningObjectTable(NULL, &spROT); hr = spROT->Register(NULL,m_pDSM, spMoniker, &m_dwDSMCookie);

[0840] The framework is registered in a similar manner to the DSM. Inthe case of the framework, the format of the item moniker is:

[0841] !HDX:RT:pid=xxxx

[0842] Note that RT (runtime) is used as this moniker is also used bythe Browser Helper Object.

[0843] The following code thus illustrates registration of the frameworkin ATL: // pUnkThis is assumed to be an IUnknown * to the frameworkitself. // This interface must be able to be queried successfully forIHDXSearchPath, // as described in section 3.3, “Advanced FrameworkFunctionality”. CComBSTR bstrDelim(“!”); CComBSTRbstrItem(“HDX:RT:pid=1234”); CComPtr<IMoniker> spMoniker; // create amoniker to the DSM hr = CreateItemMoniker(bstrDelim, bstrItem,&spMoniker); // now register it in the ROT CComPtr<IRunningObjectTable>spROT; GetRunningObjectTable(NULL, &spROT); hr = spROT->Register(NULL,pUnkThis, spMoniker, &m_dwRTCookie);

[0844] Context menus are, in general, specific to an individualapplication. If a framework wishes to implement context menus other thanthose provided by Internet Explorer, it needs to implement theIDocHostUIHandler interface. The samples described elsewhere in thisspecification all demonstrate how to achieve this in various programmingenvironments. It should be noted that it is much easier to do this inC++ than VB.

[0845] Upon application shutdown, the framework removes any referencesto the DSM or to itself stored in the ROT. Following on from theprevious examples, it does this with the following calls:

[0846] hr=spROT->Revoke(m_dwDSMCookie);

[0847] hr=spROT->Revoke(m_dwRTCookie);

[0848] The framework then calls Release( ) on the Data Source Manager tocause it to unload itself from memory. After this the frameworkterminates.

[0849] Some detail is provided below to explain how a Hendrix frameworkbehaves to support the more advanced functionality provided by theHendrix architecture. Each of these is dealt with separately. It will beappreciated by those skilled in the art, given the teaching herein, thatmodifications and alternatives are available.

[0850] Security

[0851] The framework participates in the acquisition of securitycredentials from the user, which are then passed to the DSM and on tothe respective data sources.

[0852] Display Path Management and Internationalisation

[0853] As mentioned earlier in this description, the framework isresponsible for determining which sets of displays are presented to auser, through the use of display search paths.

[0854] Search paths are implemented in the Hendrix architecture throughthe use of the IHDXSearchPath interface. The APP queries the Unknowninterface it retrieves from the ROT for this interface. The frameworkimplements this interface if it is to rely on partially-formed URLs forpage callup.

[0855] Path substitution forms the core of a number of mechanisms forHoneywell products. Two examples are internationalisation and the notionof departments in OCS.

[0856] For internationalisation, path substitution provides a mechanismto dynamically switch between different sets of displays, each built fordifferent languages. For example, a framework might start viewingEnglish displays only, stored in c:\Honeywell\displays\English. Uponpage callup, the APP requests this path from the framework, and resolvesthis to the relevant English display accordingly.

[0857] Upon change of operator, however, the framework switches languageas appropriate. If a Finnish operator were to log in, the frameworkswitches the search path to c:\Honeywell\displays\Finnish, and the APPthenceforth calls up the Finnish displays.

[0858] In OCS, an operator logs in to various departments. The currentdepartment will determine which displays the operator will view.Underlying the OCS system, displays from differing departments are eachstored in different directories. The OCS Hendrix framework thus dictateswhich displays are called up according to department, by passing therelevant display path to the APP when requested.

[0859] Frameworks have the capability of participating in the popupwindow functionality provided as part of the Hendrix toolkit. Thisparticipation consists of:

[0860] 1. The ability to specify how many popup windows are to be activeat any one time;

[0861] 2. The ability to specify if popup windows themselves areavailable to activate other popup windows;

[0862] 3. The ability to store and retrieve popup configurations

[0863] Developers of Hendrix runtimes are provided with the flexibilityof choice, as this functionality is optional; and only needs toimplemented it if it is intended to utilise popup window functionalityin the framework being developed.

[0864] The framework specifies how many popup windows are able to beloaded at any one time by exposing a Hendrix-specific property,maxPopups, to objects on the page through IDocHostUIHandler. Thisinterface allows a hosting application to extend the DOM via thewindow.external property. Thus, if the framework setswindow.external.maxPopups to two, at most two popup windows will bedisplayed at any one time.

[0865] Similarly, the framework governs whether popup windows are toactivate other popup windows by exposing a custom property,window.external.popupFromPopups, which it sets either to true or falseaccordingly.

[0866] The popup functionality of the Hendrix architecture possesses theability to store and retrieve configurations of popup windows. This isexposed by an object on every Hendrix display named “WindowManager”. Anabridged version of the IDL for the WindowManager is shown below. [object, uuid(034DB16D-AE01-11D3-BE8D-00C04F7915FE), dual,helpstring(“IPopupFactory Interface”), pointer_default(unique) ]interface IPopupFactory : IDispatch { HRESULT CreatePopupWindow([in]BSTR 1pPageFile, [in] int iXpos, [in] int iYpos, [in] int iWidth, [in]int iHeight); HRESULT SavePopupConfig([in] BSTR bstrName); HRESULTLoadPopupConfig([in] BSTR bstrName); HRESULT CloseAllWindows( ); };

[0867] In most cases the creation of popup windows is performed byobjects on the page itself, and does not require the assistance of theframework. (If the framework does wish to create popup windows, it stilldoes so by calling the CreatePopupWindow method of the WindowManagerobject embedded in the current page.)

[0868] In some embodiments, the Hendrix framework requires the abilityto close all popup windows. This functionality is often presented to theoperator as a single toolbar button in the framework. It is availablethrough the CloseAllWindows method.

[0869] Some Hendrix frameworks also store current configurations ofpopup windows for later retrieval. This is achieved via theSavePopupConfig and LoadPopupConfig methods. These methods accept astring which uniquely identifies the configuration name. In most casesthis string does little more than identify the current operator.

[0870] The Hendrix architecture, in some embodiments, incorporates anerror handling capability. Some framework support is required to enablethis functionality.

[0871] The discussion of framework implementation up until this pointincorporates only the ability to instantiate the Hendrix architecture,and call up Hendrix displays. For a large number of frameworkimplementations, this functionality will be sufficient. This isespecially the case for GUS-style frameworks, where all functionality isplaced in the displays for a system, with the framework a simple framewindow (or windows) around the web browser control.

[0872] For many other frameworks, however, greater functionality isrequired. In particular, the framework needs to be able to issuecommands (triggered by toolbar buttons or menu items, for example) tothe relevant data sources.

[0873] This scenario corresponds to binding an event fired by theframework to a method on the data source, which is functionalityprovided by the Hendrix binding engine for objects on an HTML page. TheHendrix architecture allows frameworks to participate in thisfunctionality as well, firing events through the binding engine to datasources, as shown in FIG. 35.

[0874] There are two ways Hendrix development groups constructs theirframeworks to participate in this type of data/event binding:

[0875] 1. Construct the framework user interface primarily from HTML.This is achieved in a number of ways: frames in an HTML application, orby multiple instances of the web browser control embedded in a Win32application. PlantScape's first implementation of a Hendrix framework,for example, implements the status zone and alarm zone completely inHTML. Note that this does not necessarily require extensive HTMLscripting, as these areas of HTML consist of ActiveX controls to providearbitrarily complex functionality. In this scenario, the HTML portionsof the framework conform to the Hendrix file format, including adefinition for binding data and events from an appropriate data source.The page connector on each page then simply connects to the data sourcemanager and binds events as appropriate.

[0876] 2. Construct the framework user interface using the Win32 API. Inthis case, the framework provides an object model which participates inthe Hendrix binding mechanism.

[0877] Some additional functionality that is available for use in theHendrix framework is SafeView conformance. Framework implementations arefully SafeView-compliant to facilitate full convergence of userinterfaces between systems.

[0878] Browser helper objects are covered in detail in the MSDN Library.In essence a BHO is a COM object that is loaded by Internet Explorer atstartup, and which can connect to Document Object Model events fired bythe browser and act on them accordingly by manipulating the DOM.

[0879] As an instance of the BHO gets instantiated for each instance ofInternet Explorer, it is not desirable for the BHO to start the DSM assoon as it loads. Instead, it hooks into Internet Explorer events todetect when a Hendrix page (distinguished by the use of the pageprotocol) is first loaded. The BeginNavigate2 event is most appropriatefor this purpose.

[0880] Beyond this point, the responsibilities of the BHO are identicalto those of the framework itself, and for the most part are coveredearlier in this specification. It is responsible for registration andun-registration of objects in the ROT, for the management of displaypaths, and so on. It is up to each individual development group howtheir own BHO should present configuration of this information (pathsetup, for example, or the ability to switch languages dynamically) tothe user.

[0881] In the area of context menus, the operation of the BHO isslightly different from that of the framework. This is because the BHOis not responsible for hosting the web browser control, but is merely aCOM object attached to Internet Explorer. The IDocHostUIHandlerinterface is designed primarily for web browser implementers, not forInternet Explorer itself.

[0882] It is possible, however, for an external object to override theuser interface (menus, context menus and toolbar) functionality ofInternet Explorer, through the use of the ICustomDoc interface. TheICustomDoc interface is described in the MSDN Library. It allows anobject to set the UI handler for an instance of MSHTML, and is used bythe BHO as follows:

[0883] if (IsPageProtocol( )//only do this for Hendrix pages {CComPtr<IHTMLDocument2> spDoc; CComPtr<ICustomDoc> spICD; // Setourselves up as the UI handler for IEm_spWebBrowser2->get_Document((IDispatch **)&spDoc);spDoc->QueryInterface(IID_ICustomDoc, (void **)&spICD); if(spICD)spICD->SetUIHandler(this); }

[0884] From this point the functionality is no different from any otherapplication wishing to host the web browser control.

[0885] Advanced functionality for the BHO is largely identical to thatprovided by the framework, and is summarised below.

[0886] The BHO assists in the security and authentication mechanisms ofthe Hendrix architecture just as the framework does. Unlike theframework, however, the BHO has no inherent user interface of its own.It is up to the implementer of the BHO as to what user interface isprovided to allow the operator to log on in the web browser environment.

[0887] The BHO must implement MIDXSearchPath to provide the APP with avalid search path for displays. It is up to the implementer of the BHOas to what user interface is provided to allow the user to configurethese search paths.

[0888] The BHO is able to control the behaviour of popup windows byextending the object model of the browser. Note that the mechanism a BHOuses to extend this object model is the same as it uses to overridecontext menus, as described above.

[0889] Like the framework, the BHO is responsible for retrieving systemlevel error information, and either logging these errors or (whereappropriate) presenting them to the user.

[0890] As the BHO possesses no user interface of its own, it is largelyunable to execute system-level actions. In the web browser environment,operational functionality is largely restricted to the display shown.

[0891] Hendrix displays include of a number of different user-interfacecomponents, the most common being HTML elements, VML objects,behaviours, embedded displays, and ActiveX controls. Before discussingthe requirements of ActiveX controls in the Hendrix architecture, it isworthwhile examining briefly when it is appropriate to use thosecontrols.

[0892] Performance analysis of the MSHTML rendering engine hasdemonstrated that one performance bottleneck is in the callup of ActiveXcontrols. This is recognized by Microsoft, and is not likely to changein the upcoming releases of Internet Explorer. MSHTML is capable ofmeeting the Hendrix performance targets, but displays containingcontrols will remain slower to call up than displays containing similarfunctionality implemented via other means, such as a combination ofHTML, behaviours, and script.

[0893] In general, therefore, controls are most appropriate for use inHendrix when:

[0894] It is expected that few such controls will ever exist on a singlepage.

[0895] The control contains complex user interface interaction thatwould be difficult to implement using DHTML.

[0896] The call-up performance of the control does not matter.

[0897] The control is large enough that it is unlikely that there willbe much other content on the page.

[0898] The control implements functionality that may need to be reusedin other containers, such as in Visual Basic applications.

[0899] The control already exists.

[0900] This should not imply that controls are not central to theHendrix display page architecture: world-class support of ActiveXcontrols is one of the strengths of Hendrix. Where a control is likelyto be used several hundred times on a display page, however, that samefunctionality is best implemented via other mechanisms. In otherembodiments, the functionality provided by a single large control isimplemented just as easily by a combination of DHTML and other, smallercontrols. This latter strategy has the advantage that these types ofcomposite controls are able to be built and customized completely usingthe Hendrix builder or other DHTML authoring tools.

[0901] One of the main requirements of the architecture of the preferredembodiments is its support for third-party controls. The requirements ofa control for Hendrix compliance are quite modest, and in many casesconsist of recommendations rather than rules that must be obeyed. As aresult, most third-party controls integrate smoothly into the Hendrixarchitecture.

[0902] The following description discusses the differing technologiesavailable for the implementation of Hendrix controls: primarily theActive Template Library (ATL), Microsoft Foundation Classes (MFC), andMicrosoft Visual Basic (VB).

[0903] The Hendrix architecture is not prescriptive when it comes towhich of these technologies should be used to implement controls. Aslong as controls conform to the requirements enumerated in thisdocument, they are able to be built with any of the above technologies(or even others, such as Java). However, it is worthwhile discussing thevarious features of the major technologies listed above, and consideringwhen each is appropriate to be used.

[0904] Most windows developers are already familiar with and probablyuse the Microsoft Foundation Classes (MFC). The purpose of MFC is tospeed the development of large, Windows-based applications, whichgenerally have significant GUI components. MFC does support the creationof controls. However, the support for COM in MFC was added long afterits initial implementation, and as a result its implementation issomewhat convoluted, and restricted in what it can do. In particular:

[0905] MFC does not easily support dual interfaces.

[0906] MFC controls require the MFC runtime libraries. This has animpact on size and performance, and also on the potential to deploy thecontrols via the web.

[0907] Like MFC, Visual Basic provides a convenient starting point forbuilding simple controls, as it hides most of the complexity associatedwith building the control. In addition, the later versions of VisualBasic are far more oriented to control creation than MFC, and includesupport for windowless controls and dual interfaces. In general, VisualBasic is even simpler to use than MFC. It still suffers from somerestrictions, in particular:

[0908] Controls implemented in Visual Basic still require the VB runtimelibraries. As with MFC, this produces heavier controls that are moredifficult to distribute via the web.

[0909] The performance of Visual Basic code is generally slower thancode implemented in C++.

[0910] The fact that VB hides most of the implementation details issometimes a drawback, particularly when creating controls that need toimplement non-standard functionality. The framework provides ease of useat the expense of flexibility.

[0911] The Active Template Library (ATL) was built by Microsoft from theground up as a development platform for developing the most efficient,streamlined, high-performance controls as possible. ATL includes anumber of features which make it very useful for control creation,including:

[0912] Wizards used to create COM components and controls.

[0913] Template classes for COM fundamentals such as class factories andself-registration.

[0914] Support for HDL.

[0915] Complete implementation flexibility, including support forwindowless controls, multiple threading models and dual interfaces.

[0916] ATL does, however, have its drawbacks, most notably that it isinitially more difficult to use than either VB or MFC, particularly fordevelopers familiar with either of those products. It also requires asound knowledge of COM.

[0917] As a result of the features discussed above, the followinggeneral recommendations are provided as to which technology is used toimplement controls:

[0918] Hendrix controls are, ideally, as small and lightweight aspossible. The ability of ATL to create controls without dependencies onlarge runtime libraries, which are optimised for drawing performance,and as flexible as possible, means that in many cases ATL will be themost appropriate tool for control creation.

[0919] It is recognized that in many simple controls, the performance ofVB-generated controls approach that of ATL. In addition, the performancelimitations of controls in the Hendrix architecture will ultimately restwith the MSHTML rendering engine, rather than the controls themselves.Given Visual Basic's ease of use, in many cases it offers itself as aviable alternative to ATL, particularly when large numbers of controlsare required in a short time. The dependency of Visual Basic controls onthe VB runtime libraries, however, still impose restrictions on thosecontrols, so ATL is still advised.

[0920] As previously mentioned, however, the architecture is notproscriptive when it comes to these recommendations, and the finalchoice is up to the individual developer.

[0921] The Hendrix architecture imposes very few constraints on controlsas far as what methods, properties and events they must support. As faras the architecture is concerned, controls and behaviours are generally“dumb”, and whichever properties they implement must be supplied withdata via the standard Hendrix data delivery mechanisms. This hasimplications for the builder, in how to connect data to the variouscontrol properties, but these are issues for the builder, not thecontrol.

[0922] In addition, much of the Hendrix-specific functionality requiredby controls and behaviours (data delivery, access to the data referencesdata source object model which drives the control, etc.) is alsorequired by data-bound HTML elements more generally. This functionalitywill not be implemented by the control/behaviour itself, but by custombinary behaviours that are applied to the control at authoring time bythe builder.

[0923] There are, however, a number of things that should be consideredwhen implementing a control or behaviour intended for the Hendrixenvironment. These fall into two categories: those that must besupported by all Hendrix-compliant controls and behaviours, and thosewhich are more recommendations as to how good Hendrix controls andbehaviours should behave.

[0924] The following aspects are required by all Hendrix-compliantcontrols and behaviours:

[0925] Quality Indication

[0926] A control/behaviour has any number of properties that aresupplied with data by the binding engine. For each of these properties,the control/behaviour requires some way of indicating quality. One wayto implement this functionality is by implementing each property as anobject, with its own properties of value and quality. The value is adefault property of this object, so that the following calls areidentical:

[0927] control.property1=100

[0928] control.property1.value=100

[0929] Quality indication for the property is then accessed viacontrol.property1.quality. The control sample demonstrates how thisquality mechanism is implemented in an ActiveX control. This method isideal for those controls/behaviours that have more than one bound valuewhere each one requires a separate quality indication. This situationmainly arises with more complex controls/behaviours, one example being atrend control.

[0930] Alternatively, if your control/behaviour simply requires a singlequality indication, and has one or more bound value properties, then asingle quality property is exposed on the control/behaviour. It is thena simple process to bind this quality property to the equivalent qualityproperty on the associated data source.

[0931] The major implication of this scheme is that the convergence teamhad to decide on a canonical form for this quality value. Without aconverged concept of quality, controls/behaviours designed for one datasource component will not work with other data source components.

[0932] Once a property's quality value is set, it is up to thecontrol/behaviour as to how it represents that quality indicationvisually. This, again, is another potential area for convergence, withthe potential for a standardized look and feel for controls.

[0933] Alarm Indication

[0934] Controls/behaviours which require alarm information obtain thisthrough separate alarm properties. Generally this property shall benamed “alarm”, though some controls/behaviours require a number of alarminputs so this name is not mandatory. Controls/behaviours interpretalarm parameter values according to the Hendrix canonical form for alarminformation, which is described below.

[0935] Note that in some embodiments the alarm consolidation isperformed either in the data source or sources, or in transformations inthe binding engine prior to being applied to the control. This allowsfor arbitrarily complex manipulation of alarm data, and even theprovision of alarm data from separate data sources, such as the AlarmList Manager.

[0936] Build-Time Requirements

[0937] Hendrix controls/behaviours exhibit specific build-timebehaviour, so that they are able to be configured by the unified Hendrixbuilder.

[0938] Property Binding

[0939] Hendrix controls/behaviours implement bindable properties, andsupport pessimistic binding. This implies that the control/behavioursupports the IPropertyNotifySink interface, and that the properties onthe control/behaviour are marked as both bindable and requestedit in theIDL file for the control/behaviour. Controls/behaviours built with ATLwill fire the OnRequestEdit event when a property changes, as part ofthe standard ATL implementations. Controls/behaviours built in otherenvironments will need to ensure that this event is fired asappropriate.

[0940] Persistence

[0941] Controls/behaviours must persist their configuration in ahuman-readable format in conformance with the standard forcontrols/behaviours in HTML files. In order to implement thisfunctionality the control/behaviour must implement theIPersistPropertyBag interface.

[0942] Scripting

[0943] Hendrix-compliant controls/behaviours are able to be scripted inthe standard web browser environment. To mark an object safe forinitialisation and scripting, the control/behaviour implements theIObjectSafety interface.

[0944] Zooming

[0945] Hendrix-compliant controls/behaviours are able to supportzooming.

[0946] The following aspects are recommendations as to how Hendrixcontrols/behaviours should behave. These recommendations are often to dowith the style of a control/behaviour, how it will appear to a user, andhow native it will feel in the Hendrix environment. If they are notimplemented, the control/behaviour will still function in the Hendrixenvironment, but not as well as controls/behaviours which do followthese recommendations.

[0947] Data Access

[0948] Hendrix controls/behaviours should be designed to be as dumb aspossible. They are preferably not data-aware, but instead rely on beingsupplied with data through property get/put calls by the binding engine.This design principle ensures simple, reusable controls/behaviours thatmake use of the data delivery optimisations that are part of the Hendrixarchitecture.

[0949] Object Model Consistency

[0950] Hendrix controls/behaviours aim to be well-behaved participantsin the Document Object Model, both in terms of functionality and style.Things to consider here are property naming conventions (the DOM usesmixed case, without capitalization of the first word) and the type ofevents that need to be generated (controls should aim to be consistentwith the events generated for native HTML elements). Note that sincebehaviours attach to an existing HTML element, they do not need toexplicitly expose all events native to HTML elements. The HTML elementcontinues to fire its own events whether the behaviour is attached ornot.

[0951] Of more importance, however, is the issue of consistency withexisting Honeywell object models (or at least similarity with them) andthe generation of data-oriented events. In the Hendrix architecturedata-oriented events are handled in the middle tier, with events (suchas OnDataChange) generated in the data source components. These eventsare able to be scripted. Controls/behaviours are data independent, sothe generation of data-oriented events are inappropriate for Hendrixcontrols/behaviours. Instead, the control/behaviour should generateonchange events for its various properties, which are then scripted inthe document environment.

[0952] In addition, while consistency with the DOM is a noble goal, insome cases migration concerns make it preferable to conform more closelywith the object models of existing Honeywell products.

[0953] Deployment

[0954] Hendrix-compliant controls/behaviours preferably support theability to download them from web sites, allowing easy deployment. Toenable web deployment, controls should contain a digital signature,obtainable from one of the recognized authoriztion authorities.

[0955] Stock Properties and CSS Styles

[0956] The present implementation of ActiveX controls is limited when itcomes to applying CSS style attributes to a control. However, it isanticipated that this will be vastly improved in the next release ofMicrosoft Visual Studio. In the meantime, Hendrix controls observe theCSS style attributes applied to them in an HTML page. In particular,this means using ambient properties to set the attributes for font,foreground colour, background colour and text alignment. Behaviours donot need to explicitly deal with ambient properties since they usuallyonly extend the functionality of the attached HTML element. Behaviourssimply hook into the HTML element's style object attributes if theyrequire the property values.

[0957] The Hendrix controls/behaviours support integration into theHendrix builder. The main issue to consider here is how thecontrol's/behaviour's configuration, via its property pages, is handledin the builder, and how this integration takes place.

[0958] The Hendrix builder handles control/behaviour configuration viaproperty pages. The builder also support configuration of some of themore common properties via its toolbar. These include colours, linestyles, and fonts.

[0959] Behaviours have a single requirement in order for them tointegrate with the builder. This is, behaviours expose a property whichreturns a pointer to the behaviour. The name of this property isequivalent to the behaviour's ID as specified in its OBJECT tag in theHTML document. Below is an example.

[0960] <OBJECT id=HSCIndicatorBehavior style=“LEFT:0px; WIDTH:0px;POSITON: absolute; TOP: 0px;HEIGHT:0px”classid=clsid:ABAAEE25-63F3-4F67-9C1C-0AC96A186A73><OBJECT>

[0961] <SPAN id=indicator1style=“BEHAVIOR: url(#BindingBehavior)url(#HSCIndicatorBehavior); BORDER-RIGHT: 2px inset; BORDER-TOP: 2pxinset; FONT-SIZE: 12pt; LEFT: 94px; BORDER-LEFT: 2px inset; WIDTH: 77px;BORDER-BOTTOM: 2px inset; FONT-FAMILY: Arial; POSITION: absolute; TOP:202px; HEIGHT: 164px; BACKGROUND-COLOR: lightsteelblue“></SPAN>

[0962] The reason for such a property is to allow the display builder toget a pointer to the behaviour for querying for ISpecifPropertyPages. Atthe moment it is not possible to get to any attached behaviours via apointer to the attached HTML element).

[0963] The following recommendations should also be followed to ensurecontrols/behaviours behave well within the builder:

[0964] Controls/behaviours should not contain any data-relatedconfiguration information, just properties that relate to its runtimevisual behaviour or operation

[0965] Controls/behaviours should specify property pages forconfiguration of their properties. This involves implementing theISpecifyPropertyPages interface. If implementing your control/behaviorin ATL, the property pages are simply specified via the PROP_ENTRY orPROP_PAGE macros in the property map. Behaviours should expose an‘element’ property which returns a pointer to the attached HTML element.This property is not essential but is useful when an external object(such as a custom property page) wants to access properties on theattached HTML element. Since the builder is only given a pointer to thebehaviour itself (on which it queries for ISpecifyPropertyPages), thereis no other way to get a hold of the attached HTML element. Thisproperty is required by a small selection of common property pagescontained in the builder.

[0966] One of the major decisions to make when implementing a control iswhether to make the control windowed or windowless. The Hendrixarchitecture is not proscriptive in this area, as in some situationswindowed controls are appropriate. In general, however, windowlesscontrols are more suitable for use in a browser-oriented userenvironment. The major reasons for this recommendation are:

[0967] The creation of a window for windowed controls gives them muchpoorer call-up and redraw performance than windowless controls. Theoperation of a display containing a large number of windowed controls isextremely poor.

[0968] Windowless controls support flicker-free drawing, while windowedcontrols do not.

[0969] Windowless controls support non-rectangular areas, andtransparency. Windowed controls are displayed in the document as anopaque rectangle.

[0970] Windowless controls do, however, have their own limitations. Inparticular:

[0971] At present, Internet Explorer does not support zooming ofwindowless controls. This is a major limitation and as such may mean theimplementation of a windowed control is unavoidable.

[0972] Implementing a large, sophisticated control with a complex userinterface as windowless is far more difficult than implementing awindowed version of the same control. Implementation effort increasesrapidly once a control incorporates a large number of user interfaceelements.

[0973] Standard Windows user interface elements, such as scroll bars,comboboxes, checkboxes, etc. have standard windowed implementations.These elements may be created in a windowless control, but theirwindowed nature means they will not participate in the z-order scheme ofa windowless control (see FIG. 36). At present, no library of windowlessUI elements exists, meaning that all such elements need to beimplemented using standard GDI functions in a windowless control. (Notealso that while VB6 permits the creation of windowless controls, it doesnot allow these controls to contain windowed UI elements.)

[0974] As a result of the advantages and disadvantages of windowlesscontrols discussed above, the Hendrix architecture makes the followingrecommendations:

[0975] Hendrix controls are preferably implemented as windowlesscontrols, particularly when they are simple controls, and where it isexpected that several such controls are to be placed on a single displaypage. This is only recommended, however, if display page and controlzooming as supported by Internet Explorer is not important.

[0976] Where a control is expected to be large and complex, to provide alarge amount of self-contained functionality, and not be expected tointeract with the rest of a display page, then a windowed control isacceptable.

[0977] The implementation of drawing in each control will depend uponthe tool being used to generate the control. However, no matter whattools are used to develop the controls, all Hendrix-compliant controlsprovide support for:

[0978] Zooming; and

[0979] Printing.

[0980] In addition, while the target container for most Hendrix controlswill be MSHTML, it is highly preferred that controls are developed to becontainer-independent. In other words, Hendrix controls work in anycontainer, such as Visual Basic and Office 2000. The followingdescription discusses these issues in further detail.

[0981] The current plans for zooming within the Hendrix architecture areto emulate the zooming functionality of HTML pages generated byPowerPoint 2000. Microsoft has some plans for implementing zooming inHTML, but not in the Hendrix timeframe.

[0982] The basic concept for zooming is quite simple. Each display pageis contained in a single HTML <DIV> tag, which is given both a size anda font size. All objects within the page are defined in terms of theseattributes, where:

[0983] Object size and position is expressed as a percentage of itsparent element.

[0984] Object font is expressed as a percentage of the parent font.

[0985] When a page changes its zoom level, the containing <DIV> isresized appropriately, changing the size and position of all objects onthe page. It also has its font size recalculated, propagating font sizechanges down to all page objects. This operation is performed by asimple few lines of script on the page, or may alternatively beperformed by the data source connector on the page.

[0986] This approach has implications for how controls are implemented.First consider the case of a simple control, displaying a singlealphanumeric string value within a bounding rectangle. In this simplecase, whenever the control is resized, it's graphical content (therectangle) is scaled to fit its new size. In other words, the graphicalcontent is scaled upon every size change. The font for the text in thecontrol is applied using the ambient font property, which in HTML is setusing CSS style attributes. In Hendrix, this font will be set to apercentage of the parent font.

[0987] Thus for this simple control, when the page is zoomed, thecontrol's graphical content will zoom, and its font will change size aswell, presenting the impression of zooming to the user consistent withother HTML elements on the page.

[0988] This behaviour is also consistent with scripting within the page.When the control is sized, its graphical content scales, independent ofthe font, which may also be changed via script. When a user resizes thecontrol via script, they do not expect to see its font change as well.

[0989] This simple model is the one recommended for Hendrixcontrols/behaviours, as it integrates as closely as possible withexisting CSS mechanisms. For more complex controls/behaviours, however,it is often desirable that a scripted size change does not scale thegraphical content of the control/behaviour, but merely clips it. In thiscase, the zoom factor is independent from the object's current size. TheHendrix zooming model supports this type of control/behaviour asfollows:

[0990] Font properties are set explicitly as properties on the control.In the behaviour's case the font properties are on the attached HTMLelement's style object.

[0991] A control retrieves the ambient font property, and uses its sizerelative to the explicitly set font size to calculate its own scalingfactor. It uses this scaling factor to determine how to zoom itsgraphical content.

[0992] Resizing the control/behaviour does not change the control's orHTML element's scaling factor.

[0993] This type of behaviour is probably most appropriate for large,complex controls with numerous font selection properties, such as achart. As it uses the CSS mechanisms in a non-standard way, it is notlikely to work well with the improvements Microsoft has planned forActiveX controls in the next release of Visual Studio, and shouldtherefore be used only when necessary.

[0994] All Hendrix-compliant controls support printing. This involvesconfiguring the device context mapping mode in such a way that thecontrol renders itself correctly for all devices (screen, printer, etc).

[0995] It is highly preferred that all Hendrix controls/behaviours aredeveloped to be container-independent.

[0996] All Hendrix controls/behaviours support scripting, allowingproperty get/put operations via the IDispatch interface. As a result,all Hendrix control/behaviour properties are standard OLE data types.

[0997] Complex data structures, such as array data, is supported by theHendrix binding engine and data source components (refer to the HendrixArchitecture Overview and Reference and the Data Source ComponentImplementation Guide). From a control's/behaviour's perspective, arraydata is supported by using a SafeArray. The Hendrix ImplementationIssues document discusses the construction of SafeArrays.

[0998] The choices for threading in controls is very limited—fullcontrols conform to the Single-Threaded Apartment threading model. Thisis due to the requirement of the GUI component of the control to receivesynchronized calls.

[0999] The Hendrix Implementation Issues document discusses thedifferent threading models available in ATL.

[1000] Advanced error handling for COM objects (including ActiveXcontrols and DHTML behaviours) centres around the use of theISupportErrorlnfo interface. This interface and those associated with itallow an object to return detailed error information to a client.

[1001] In the Hendrix environment, this error information is passed tothe script engine when an error is encountered, which gives a user theopportunity to view this information. For this reason, the support ofthe COM error interfaces in Hendrix controls is recommended.

[1002] It should be recognized, however, that most operations performedon a control in the Hendrix architecture will typically be via thebinding engine. In this case, there is no real opportunity for thearchitecture itself to relay this information back to the user. Even ifthe various frameworks provided such a mechanism, the process controlenvironment typically relies on visual information within the control toconvey bad information (such as displaying itself as inverse forout-of-bound data). Control implementers are encouraged, therefore, toprovide error information through the user interface of the controlwhere possible. More serious types of internal errors, such as generalprotection faults, are of course beyond the scope of this mechanism.However, all exceptions which are thrown within a control should becaught and then return an appropriate failed HRESULT to the callingclient. Note that there are quite a few groups of Windows API callswhich inherently throw exceptions. When using these API functions it isrecommended to wrap them in try/catch blocks which catch all possibletypes of exceptions which are thrown by the function(s) in question.That way the call is returned so the client object does not lock.

[1003] The following description outlines the Hendrix canonical form forquality. How each individual control/behaviour interprets this qualityinformation is up to it.

[1004] The Hendrix quality value is implemented as a vendor-specificextension to the 32-bit OPC Quality word. In Hendrix, “Quality” is aslightly more loose term than in OPC, and is used to indicate anyinformation which affects the visual representation of a UI element,such as alarm or security information. Thus the OPC quality value is notsufficient for the requirements of Hendrix. It does, however, provide agood basis for it, and its extensibility mechanism allows it to fulfilall Hendrix requirements.

[1005] The OPC Quality word has the following structure: ReservedExtension QQ.SSSS.LL

[1006] where:

[1007] QQ=quality bit-field

[1008] SSSS=substatus bit field

[1009] LL=limit status bit field

[1010] These are interpreted as follows:

[1011] Quality

[1012] 00=>Bad. Value is not useful. Reasons indicated by substatus.

[1013] 01=>Uncertain. Quality is uncertain for reasons indicated bysubstatus.

[1014] 10=>N/A. Notused.

[1015] 11=>Good. Quality of the value is good. More information can beobtained in substatus.

[1016] Substatus

[1017] The layout of this field depends on the value of the Qualityfield.

[1018] Substatus for Bad Quality:

[1019] 0000=>Non-specific.

[1020] 0001=>Configuration error.

[1021] 0010=>Not connected

[1022] 0011=>Devicefailure

[1023] 0100=>Sensor failure

[1024] 0101=>Last known value

[1025] 0110=>Comm failure

[1026] 0111=>Out of service

[1027] Values 8-15 are not used by OPC.

[1028] Substatus for Uncertain Quality:

[1029] 0000=>Non-specific

[1030] 0001=>Last usable value

[1031] 0100=>Sensor not accurate

[1032] 0101=>Engineering units exceeded

[1033] 0110=>Subnormal

[1034] Values 2-3, 7-15 are not used by OPC.

[1035] Substatus for Good Quality

[1036] 0=>Non-specific. The value is good.

[1037] 6=>Local override. Value has been entered manually.

[1038] Other values are not used by OPC.

[1039] Limit Status

[1040] 0=>Not limited.

[1041] 1=>Low limited. The value has pegged at some lower limit.

[1042] 2=>High limited. The value has pegged at some high limit.

[1043] 3=>Constant. The value is constant and cannot move.

[1044] The Extension Field

[1045] In Hendrix, the 8-bit extension field is used to either representa confidence value (as in Uniformance), or a discrete bitmap of qualityvalues (as in most other systems), as follows: Empty (18 bits) Q.C.A.RSeverity (10 bits)

[1046] where:

[1047] Q=alarm condition quality bit

[1048] C=alarm condition bit

[1049] A=acknowledgement status

[1050] R=acknowledgement requirement

[1051] Severity=alarm severity

[1052] These are interpreted as follows:

[1053] Alarm Condition Quality

[1054] 0=>Alarm condition calculation is valid.

[1055] 1=>Alarm condition calculation is invalid (for example bad limitvalue).

[1056] Alarm Condition

[1057] 0=>Alarm condition is off, no alarm.

[1058] 1=>Alarm condition is on, alarm.

[1059] Acknowledgement Status

[1060] 0=>Alarm is not acknowledged.

[1061] 1=>Alarm is acknowledged.

[1062] Acknowledgement Requirement

[1063] 0=>Acknowledgement is not required.

[1064] 1=>Acknowledgement is required.

[1065] Severity

[1066] This is a value ranging from 1 to 1000. Systems should spreadtheir alarm severities across this range. It is envisaged that theAlarms & Event team will define a converged definition of severitybreakdowns for Honeywell systems—when this is done controls use thisdefinition accordingly. In the meantime the controls interpret thisvalue as they see fit.

ADVANTAGES OF THE PREFERRED EMBODIMENTS

[1067] The common HMI architecture for industrial user interfaces thatis provided by the preferred embodiments of the invention provide manyand considerable advantages. Not only to they make use of and build uponcapabilities of existing Honeywell-developed HMI systems, but also inaddressing future directions in technology, as well as anticipatedmarket requirements. By way of the example, the advantages of thepreferred embodiments include:

[1068] Robustness—as the user interface eliminates, or at leastminimizes, any potential loss of view.

[1069] Migration path—an acceptable migration path from existing systemsto the invention is provided.

[1070] Single builder and runtime—the architecture facilitates thedevelopment of a single builder and runtime to be used with the variousHoneywell or other systems. While there is flexibility of implementationto allow tailoring of the system, there is also an inherent ability forthe architecture to drive unification of the underlying mechanisms.

[1071] Future proofing—use of the preferred embodiments allows leverageto be gained from present and future state-of-the-art technology. Thepreferred embodiments are also closely coupled with industry standards,enabling it to adapt easily to future technological trends. Thearchitecture is also open and extensible.

[1072] Powerful graphics rendering—the preferred embodiments allowfuture user interface developments to leverage the current state of theart in graphics rendering capabilities, for both vector and rastergraphics objects.

[1073] Openness of display elements—the user interface facilitates theinclusion of non-proprietary display elements (for example, HTML, 3rdparty controls and the like) which have their values bound to processdata.

[1074] Facilitation of “value-add” developments—the architectureprovided by the preferred embodiments facilitates developments that addvalue for the markets targeted by the provider of the system as opposedto expending effort developing commodity deliverables such as graphicsrendering and display drawing functionality.

[1075] Restricted navigation and control—a user's view of plant data isable to be restricted on a per-operator basis, according to factors suchas security level. Moreover, the controls are inherently safe andsecure.

[1076] Fast, efficient communications—the communications subsystem isboth fast and efficient. Many existing HMIs provide extremelylow-bandwidth communications systems for remote plant access, and thiscapability is retained by the preferred embodiments, as required.

[1077] Industrial operator keyboard support—the preferred embodimentscontinue to support any industrial operator keyboards used by currentsystems.

[1078] Persistent alarm and status indication—an operator is providedwith constant access to alarm and status information.

[1079] Performance—both page callup and data update performance areexcellent.

[1080] Internationalisation—the displays are internationalised easily.

[1081] Restricted operating system or screen access—an operator's accessto the underlying operating system, and the desktop is limited, asrequired. This includes support for fall-screen lock mode, or screenreal-estate management systems such as SafeView.

[1082] Animation services—industry-standard animation services areprovided, with facilities for such behaviours as blinking. Animationcapabilities are comparable with what users currently expect from Webpages.

[1083] Third-party ActiveX control container—the preferred embodimentshave the ability to embed third-party ActiveX controls in processdisplays, and link these controls to process data. The user interface isalso robust, even under the influence of badly-behaved controls.

[1084] Integration of data from multiple sources—users are able toaccess multiple business information data sources while within theprocess control environment. The globally-accessible information spaceof the internet has meant that the ability to merge information systemsin this way is increasingly becoming a customer expectation. In someembodiments that integration takes the form of embedding web pagecontent within process displays, while in other embodiments it involvesmore extensive integration of information systems. Integration goesfurther than simply integration of web page content, however. In themore preferred embodiments the user interface architecture is openenough to allow seamless integration with data from multiple sources.Instead of providing this integration in a coarse manner—such as largeActiveX controls accessing third-party data programmatically—thisintegration is as fine-grained as possible. The architecture of the morepreferred embodiments is powerful and flexible enough to provide theability to bind data to discrete elements within a display page.

[1085] Consolidation of data from multiple Honeywell systems—somewhatrelated to the previous advantage, the preferred embodiments allow asingle display page to display data from multiple Honeywell systems.

[1086] Casual access to process data via web browser—this advantage isin many ways the corollary of the previous one. Users are able to accessprocess data via a standard web browser. There are many ways to providethis functionality, but the more preferred embodiments utilise HMIarchitecture that makes this integration completely seamless.

[1087] Encapsulation—encapsulation of the displays is supported and,where necessary, is equivalent to the functionality provided by currentsystems. Encapsulation allows reuse of both content and script in a userdisplay.

[1088] Faceplate functionality—the preferred embodiments, by themechanisms inherent in the architecture, support existing and futurerequirements for the display of faceplate data.

[1089] Although the invention has been described with reference tospecific examples, it will be appreciated by those skilled in the artthat it may be embodied in many other forms.

1. A Human Machine Interface (FWI) including: a display page including aplurality of display page elements; a data source manager including aplurality of data source components; and a binding engine whichtransfers data and commands between the data source components and thedisplay page elements.
 2. An HMI according to claim 1 wherein thedisplay page further includes a plurality of infrastructure components.3. An HMI according to claim 1 wherein the data source components areserver system specific data source components.
 4. An HMI according toclaim 1 wherein each display page has its own corresponding bindingengine.
 5. An HMI according to claim 1 wherein the individual datasource components are shared by more than one binding engine.
 6. An HMIaccording to claim 1 wherein the display page acts as a container forthe page elements that make up the display page and provides the primaryuser interface thread of execution.
 7. An HMI according to claim 1wherein the page elements include any one or more element that can beincluded in an HTML file.
 8. An HMI according to claim 7 wherein thepage elements include one or more of: ActiveX controls; VML graphicselements; HTML elements; HTML scriptlets; and Java applets.
 9. An HMIaccording to claim 1 wherein the display page is constructed using amixture of standard HTML and XML tags.
 10. An HMI according to claim 9wherein the HTML describes presentation aspects of the display page andthe XML tags describe what data is required for the page and how thatdata is to be applied to the page.
 11. An HMI according to claim 2wherein the infrastructure components assist with the parsing of an XMLcontent of the display page, the delivery of data to the display pageand the initiation of server commands from display page elements.
 12. AnHMI according to claim 1 wherein, at run time, the display page appearsas an instance of a standard Document Object Model (DOM).
 13. An HMIaccording to claim 12 wherein the DOM is the standard for the industryto which the HMI is applied.
 14. An HMI according to claim 12 whereinthe DOM provides the destination for data provided by the bindingengine.
 15. An HMI according to claim 14 wherein the DOM furtherprovides the basis for the display page scripting environment.
 16. AnHMI according to claim 1 wherein the display pages are capable of beingencapsulated and re-used as encapsulated displays.
 17. An HMI accordingto claim 16 wherein the encapsulation includes the parameterisation ofany data references in the display page and the addition of properties,methods and events that allow the encapsulated display to act as a fullyfledged component.
 18. An HMI according to claim 17 wherein theencapsulated displays are embeddable.
 19. An HMI according to claim 18wherein the encapsulated displays are linked into containing displaypages.
 20. An HMI according to claim 1 wherein the display page is HTMLbased.
 21. An HMI according to claim 1 wherein the data source managermanages a plurality of server system specific data source componentsthat encapsulate the details of delivering data to and from particularserver systems.
 22. An HMI according to claim 1 wherein each data sourcecomponent presents data from a server system in the form of ahierarchical object model.
 23. An HMI according to claim 1 wherein thedata source manager pulls the separate data source component objectmodels together into a unified data source object model (DSOM) that isused as the source of data for the binding engine.
 24. An HMI accordingto claim 23 wherein the data source components are informed of the datarequirements for a particular display page by means of a data sourcedefinition that is stored as part of an HTML/XML display page file. 25.An HMI according to claim 1 wherein the server systems include one ormore of a variety of different server system, a small subset of whichincludes the server systems provided by Honeywell Limited and that areknown as: Plantscape; Enterprise Buildings Integrator; TPS; TPA; QCS;Uniformance; OPC; and HCI.
 26. An HMI according to claim 12 wherein thedata binding engine takes the data provided by the data source objectmodel and applies it to the display page.
 27. An HMI according to claim26 wherein the data binding engine takes the data provided by the datasource object model and applies it to the display page in a way definedby binding definitions contained in the HTML/XML display page.
 28. AnHMI according to claim 27 wherein each display element that requiresdata has an associated binding definition that defines what data isrequired for the element and how it is to be applied to the element. 29.An HMI according to claim 26 wherein the data binding engine is able tobind data to any property of the DOM.
 30. An HIM according to claim 26wherein the DOM includes the body element and any container elementsthat are used to organise other elements on the display page.
 31. An HMIaccording to claim 26 wherein the binding engine uses transformations toperform the transfer of data from the data source object model to thedisplay page.
 32. An HMI according to claim 31 wherein thetransformations transfer the data directly from the data source objectmodel to the display page.
 33. An HMI according to claim 32 wherein thetransformations transforms the data as they transfer the data.
 34. AnHMI according to claim 32 wherein the transformations include userwritten “OnDataChange” scripts and data driven page element “dynamics”such as rotation, path animation and break point animation.
 35. An HMIaccording to claim 32 wherein the transformations are binary components.36. An HMI according to claim 32 wherein the transformations are writtenusing an XML syntax and script code.
 37. An HMI according to claim 12wherein the binding engine executes in an apartment managed by the datasource manager and transfers data from the data source object model tothe display page in a very efficient manner.